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Preface 


This  report  summarizes  an  investigation  which  examined  the 
structured  design  methodology  applied  to  an  operational  flight  pro- 
gram (OFP).  Several  design  techniques  are  successfully  applied  to 
a particular  OFP.  Hypothetical  software  modifications  illustrate  the 
advantages  of  structured  design  OFP  software  over  a current  software 
implementation.  Software  life-cycle  effects  of  structured  designed 
OFPs  are  briefly  described.  An  OFP  familiarization  and  design 
methodology  is  developed  for  avionics  software  engineers /contract 
monitors.  The  report  is  written  for  a reader  who  possesses  a basic 
knowledge  of  software  development  and  who  understands  the  struc- 
tured design  methodology. 

I wish  to  express  my  special  thanks  to  Captain  James  B. 

Peterson  for  his  advice  and  leadership  as  my  thesis  advisor.  A 
special  thanks  also  goes  to  my  thesis  sponsor,  Mr.  Ajmel  Dulai,  for 
his  patience  and  vast  knowledge  of  avionics  concepts.  I also  wish  to 
express  my  appreciation  to  Dr.  Gary  Lament  and  Professor  Charles 
Richard  for  their  advice  and  support,  and  to  Mrs.  Joyce  Clark  for 
the  excellent  job  typing  the  final  version  of  this  thesis.  Finally,  I 
wish  to  thank  my  wife,  Pat,  and  our  children  for  their  patience,  under- 
standing and  love  throughout  this  thesis  endeavor. 
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Abstract 

Constantine's  structured  design  methodology  is  applied  to  a 
real-time  (flight)  software  program.  A modified  finite-state  tech- 
nique is  successfully  applied  to  an  operational  flight  program  (OFP) 
ma inloop.  Transform  and  transaction  analysis  are  successfully 
applied  to  mainloop  tasks.  Each  technique  is  demonstrated  to  show- 
avionics  software  engineers/contract  monitors  "how  to  get  started"  on 
a design.  Two  hypothetical  software  modifications  illustrate  advan- 
tages of  structured  design  over  the  current  software  implementation. 
Short  and  long  term  effects  of  structured  designed  OFPs  are  briefly 
described.  An  OFP  familiarization  and  design  methodology  is 
developed  for  avionics  software  engineers /contract  monitors.  - 

Structured  design  techniques  are  beneficial  to  the  software 
engineer/contract  monitor  during  initial  understanding  of  OFP  design 
requirements  from  a draft  Part  I specification.  Design  alternatives 
may  be  considered  and  the  software  producers  interpretation  of 
design  requirements  may  be  verified.  This  effort  was  sponsored  by 
the  Aeronautical  Systems  Division  (ASD/ENALA)  located  at  Vv  right- 
Patterson  Air  Force  Base,  Ohio. 
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SOFTWARE  STRUCTURE  DESIGN  TECHNIQUES 
AUDI  IED  TO  EMBEDDED  COMPUTER 
SYSTEM  SOFTWARE 


I.  Introduction 


Background 

General.  In  recent  years,  sophisticated  and  expensive  Air 
Force  Computer  programs  ^software)  used  in  avionics  systems  have 
been  relatively  inflexible,  difficult  to  repair,  and  have  required 
extensive  updates  to  keep  pace  with  state-of-the-art  improvements  in 
computer  technology  and  changing  operational  requirements.  Nor- 
mally, in  a software  development  program,  deadlines  and  cost  are 
the  major  concerns.  As  a result,  the  importance  ol  the  design  phase 
is  greatly  de-emphasized.  There  is  a great  tendency  to  start  coding 
software  at  the  beginning  of  the  project.  Since  the  design  phase  is, 
in  many  cases,  "cut  short,"  errors  result  which  remain  unnoticed 
until  after  system  implementation.  In  addition,  there  is  usually  little 
concern  about  future  repair  and  update  i maintenance)  requirements, 
and  the  efficiency  and  ease  with  which  that  software  maintenance  can 
be  performed. 

Design  Approaches.  Some  avionics  software  designs  have  been 
accomplished  with  a "bottom-up"  approach  by  developing  software 
before  addressing  functional  interface  and  integration  problems. 
Recently,  more  successful  designs  have  been  accomplished  with  a 
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"top-down"  approach  in  which  the  "top"  is  assumed  to  be  a firm, 
fixed  requirements  specification  and  hardware  architecture.  It  had 
been  assumed  that  the  data  structure  was  already  established.  In 
some  cases,  these  types  of  assumptions  change,  and  the  designer 
must  then  back-track  to  update  his  design. 

More  recently,  a software  design  methodology  called 
"structured  design"  has  received  much  attention.  This  methodology, 
which  produces  a modularized  software  design,  allows  easier  system 
implementation  and  maintenance  than  previous  approaches  permitted. 
Cost  effectiveness  is  usually  improved  with  the  use  of  this  design 
method,  and  program  complexity  is  reduced  (Ref  40).  There  has 
been  an  attempt  to  apply  this  design  methodology  to  a real-time 
system  (Ref  20).  At  the  time  of  this  writing,  the  author  is  unaware  of 
any  efforts  to  apply  this  methodology  to  operational  flight  software. 

Typical  Software  Problems.  Avionics  software,  like  automatic 
data  processing  (ADP)  software,  is  not  without  its  share  or  problems. 
In  fact  the  typical  problems  associated  with  both  types  of  software  are 
very  much  alike.  In  the  avionics  software,  there  are  similar  indica- 
tions of  high  project  costs  and  low  or  poor  software  reliability  (Ref 
10:477,479;  and  36:228).  However,  there  are  other  problems  with 
avionic  software  which  need  to  be  discussed. 

Recently,  it  has  been  suggested  that  avionics  software  is  being 
used  like  a "band-aid.  " That  is,  the  lack  of  early  specified,  firm, 
explicit  requirements  contributes  to  the  idea  that  avionics  software 
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project  (Rot'  10:478). 

The  uncertainty  of  software  module  interfaces  in  a largo  pro- 
gram causes  considerable  anxiety  for  managers.  Problems  lre- 
quentlv  occur  here,  and  module  design  or  debugging  may  require 
several  iterations.  Designing  a set  of  "milestones"  may  help  moni- 
tor project  status,  but  it  appears  to  be  beneficial  it  a hierarchical 
structure  chart  of  the  modules  is  constructed  as  early  as  possible. 
Module  interlaces  should  also  be  defined.  This  approach  helps  in 
evaluating  design  alternatives  iRet  10:4781. 

Normally,  most  avionics  software  lacks  the  flexibility  of  being 
reuseable.  Software  procurement  for  avionics  usually  results  in  new 
software  for  each  new  flight  computer.  This  redevelopment  proce- 
dure is  extremely  costly.  Most  software  can  not  be  readily  changed 
to  meet  the  overchanging  threat  environment.  It  is  unmaintainable  by 
the  government,  and  difficult  to  maintain  even  by  the  original  vendor 

(Ref  30:228-229). 


Purpose 

[ lie  purpose  of  this  report  is  to  present  the  results  of  an  investi- 
gative effort  to  apply  the  structured  design  methodology  to  part  of  an 
operational  flight  program.  Computer  software  developed  for  avionics 
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software  systems  by  this  design  method  should  t>e  easier  to  imple- 
ment and  undersUuid.  Complexity  should  be  reduced,  and  the  soft- 
ware should  be  less  difficult  to  maintain  and  more  cost-effective  with 
respect  to  life-cycle  costs.  A generalized  approach  or  methodology 
for  the  design  of  avionics  operational  flight  software  will  be  devel- 
oped. It  will  include  the  use  of  structured  design.  The  objective  of 
the  methodology  will  be  to  provide  Air  Force  avionics  software 
enginee r s /cont rac t monitors  with  an  additional  method  to  understand 
the  requirements  definition  for  preliminary  design  and  management 
of  operational  flight  software. 

Scope 

In  order  to  more  realistically  investigate  structured  design 
applied  to  avionics  operational  flight  software,  it  would  be  helpful  to 
investigate  a real  system.  The  I’AVE  TACK  operational  flight  soft- 
ware (see  Chapter  111)  draft  Part  1 specification  will  be  used.  Due  to 
the  complexity  of  the  PAVE  TACK  requirements  and  the  length  of 
time  permitted  for  this  study,  the  structured  design  methodology  will 
not  apply  to  the  entire  PAVE  TACK  flight  program  software. 

Since  structured  design  is  well  documented  ^ Kef  34;  40),  this 
study  will  be  limited  by  purposefully  halting  the  design  process  at 
certain  points  with  the  specific  purpose  of  showing  the  software 
engineer  "how  to  get  started"  on  a design.  This  approach  allows 
several  design  techniques  to  be  used.  These  techniques  are  known 
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and  well  documented.  Therefore,  the  tecliniques  will  be  demon- 


strated, not  taught. 

The  draft  and  final  PAY E TACK  preliminary  design  (Part  II 


specifications  will  be  used.  No  attempt  will  be  made  to  modify  either 
specification  or  produce  any  program  code.  Testing  of  any 
redesigned  software  and  access  to  the  PAVF  TACK  computer  hard- 
ware will  not  be  required. 


P reliminary  Rationale 

It  was  desirable  to  have  a clear  and  concise  operational  flight 

program  (OFP)  design  (Part  1)  specification  at  the  start  of  this  invest- 

\ 

igative  effort.  The  purpose  of  this  specification  is  to  supply  the 
designer  with  a comprehensive  and  unambiguous  software  require- 
ments definition  for  the  OFP.  Thus,  all  appropriate  and  necessary 
information  would  be  available  to  the  software  designer. 

It  was  anticipated  that  a reasonable  learning  curve  would  be 
experienced  during  the  initial  phases  of  the  design  investigation. 

There  was  previous  personal  experience  with  defining  and  designing 
from  written  software  requirements,  but  no  experience  with  avionics 
software  and  no  prior  knowledge  of  OFP  concepts,  in  addition,  there 
was  no  previous  personal  experience  with  AFSC  Part  1 specifications 
per  se. 

P'inally,  it  was  not  known  whether  or  not  structured  design  could 
be  applied  to  an  OFP  or  any  part  of  an  OFP.  If  structured  design 
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techniques  could  be  used,  then  another  aid  would  exist  which  would 
allow  avionics  software  engineers /contract  monitors  to  cope  with  the 
problems  of  interpreting  OKI’  software  design  specifications.  In 
addition,  it  would  aid  in  making  better  decisions  and  suggestions  about 
design  alternatives. 

Assumptions 

The  reader  should  be  familiar  with  the  basic  concepts  of  an 
OFP.  However,  if  this  is  not  the  case.  Appendix  A briefly  discusses 
basic  concepts.  This  brief  discussion  on  flight  software  concepts 
(Appendix  A)  was  included  since  many  people  are  interested  in  soft- 
ware design,  but  avionics  flight  software  is  quite  different  from  nor- 
mal data  processing  software  applications.  It  is  assumed  that  tiie 
reader  understands  the  structured  design  methodology,  its  techniques, 
and  its  principles. 

Finally,  any  statements  made  by  the  author  concerning  flight 
software,  PAVE  TACK,  structured  design,  Air  Force  specifications, 
or  anything  associated  with  this  research  effort  is  strictly  the  author's 
interpretation  of  that  information  and  bears  no  official  judgment  on 
behalf  of  the  Air  Force.  The  author  bears  sole  responsibility  for  this 
research  and  report  effort. 

Development  Plan 

Chapter  LI  briefly  discusses  some  problems  associated  with  Air 
Force  software  development,  concepts  of  a software  architecture  for 
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flight  program  managers,  and  presents  a description  of  the  struc- 
tured design  methodology. 

Chapter  III  presents  a brief  description  of  the  PAVE  TACK 
operational  flight  program. 

Chapter  IV  discusses  the  initial  approach  taken  for  this  investi- 
gation, difficulties  encountered,  and  how  the  approach  was  revised 
and  applied  to  achieve  meaningful  results. 

Chapter  V presents  a discussion  on  the  effects  of  two  hypothet- 
ical software  modifications  to  certain  parts  of  the  designs  from 
Chapter  IV  and  the  current  PAVE  TACK  software.  Short  and  long 
term  effects  associated  with  OFP's  designed  using  structured  design 
techniques  are  also  discussed. 

Chapter  VI  presents  an  OFP  design  methodology  developed  for 
avionics  software  engineers  and  contract  monitors.  It  is  a general- 
ized design  approach  which  consists  of  three  phases:  (1)  understand- 
ing the  flight  program  requirements;  (2)  use  of  a technique  for  under- 
standing flight  program  tasks  and  task  sequencing;  and  (3)  use  of 
structured  design  techniques  for  task  design. 

Finally,  Chapter  VII  presents  results  and  conclusions  of  this 
investigation.  Some  recommendations  are  also  made  for  future 
efforts. 
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II.  Tow  a rd  the  St  nu:  tu  ring  ot  Computer  Software 


Int  rotluc  tion 

This  chapter  briefly  discusses  certain  problems  associated  with 
Air  Force  software  development.  Some  concepts  for  flight  program 
managers  about  software  architecture  are  also  presented.  Finally,  a 
description  of  a recent  software  design  technique  winch  improves  the 
architectural  design  of  software  and  aids  in  reducing  life-cycle  costs 
is  presented.  The  information  discussed  in  this  chapter  can  be 
applied  to  software  in  general  te.g.  algorithm  development! . 

The  Problem/ Coding  Syndrome 

From  the  very  beginning,  a person  learning  to  program  a com- 
puter is  taught  to  understand  the  problem  to  be  solved,  devise  a 
solution  algorithm,  and  finally,  code  that  algorithm  in  a suitable 
programming  language.  Since  this  methodology  is  taught  at  a basic 
level,  it  seems  to  stay  with  a person  forever.  For  many  years  this 
problem/coding  tradition  lias  been  a part  of  the  software  life-cycle. 

The  software  life-cycle  is  well  known  by  software  professionals 
(Ref  1:4).  However,  as  shown  in  Fig.  1,  the  requirements  definition 
phase  and  a major  portion  of  the  design  phase  have  been  bypassed. 

The  design  phase  consists  of  preliminary  or  system  level  design  (Ref 
22:14),  and  detailed  design.  In  Fig.  1,  the  shaded  area  within  the 
design  phase  represents  only  part  of  the  detailed  design.  See 


reference  12  for  further  details.  The  importance  of  the  software 


requirements  definition  ("what"!  and  design  ("how")  cannot  be  over- 
emphasized in  any  Air  Force  software  development  efforts. 

The  software  requirements  and  design  phases  must  be  accom- 
plished so  that  the  end-item  software  system  satisfies  the  user's 
requirements,  is  more  easily  understood  (reduced  complexity),  and 
is  maintainable.  These  attributes  will  help  to  significantly  decrease 
total  software  life— cycle  costs.  There  is  almost  a direct  relationship 
between  the  requirements /design  phases  and  the  operational  phase. 

Software  maintenance  occurs  in  the  operational  phase  (Ref  1:6; 

12:25)  of  the  software  life-cycle.  Latent  software  errors  are  gener- 
ally discovered  at  this  time  (Ref  1:6).  This  category  of  errors  (i.  e. 
latent)  is  usually  due  to  poor  requirements  definition,  poor  design 

I 

effort,  or  both.  Generally,  the  later  the  errors  are  found  the  more 
costly  they  are  to  correct  with  respect  to  effort  and  time  (Ref  12:5). 

It  is  well  known  that  software  life-cycle  costs  are  high  and  are  con- 
tinuing to  increase.  Therefore,  software  development  can  no  longer 
be  taken  lightly. 

The  Air  Force  has  been  involved  with  the  procurement  of  aero- 
nautical system  software  for  many  years,  but  recently  has  indicated 
that  maintenance  and  support  of  weapon  system  software  throughout 
the  life-cycle  may  be  accomplished  by  the  Air  Force  if  deemed  cost 
effective.  Since  new  weapon  systems  have  a long  lead-time  and  tech- 

I 1 

nology  (i.e.  software  and  hardware)  and  mission  requirements  are  I 
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constantly  being  improved,  it  is  very  probable  that  an  active  modifi- 


cation and  enhancement  program  for  any  particular  avionics  software 
will  be  generated. 

R equir ements  1 ngineering 

The  purpose  of  the  requirements  definition  phase  in  the  soitware 
life-cycle  is  to  completely  and  unambiguiously  document  an  interpre- 
tation of  the  software  requirements  necessary  to  satisfy  the  system 
specification.  This  phase  of  the  software  life-cycle  can  be  consid- 
ered the  most  critical  (Ref  1:5).  A Part  1 software  specification 
(design)  contains  the  requirements  information  peculiar  to  the  design 
and  development  of  a particular  software  system  (Ref  2:15). 

The  requirements  represent  a complete  analysis  of  "what"  (not 
"how")  one  is  trying  to  accomplish  with  the  software  (Ref  22:14)  or 
what  the  software  product  will  do,  and  serves  as  a basis  for  common 
agreement  among  all  parties  concerned  (Ref  12:5).  A well  detailed 
description  of  "how"  these  requirements  are  to  be  achieved  is  accom- 
plished in  the  design  phase  of  the  software  life-cycle. 

In  general,  software  development  is  divided  into  many  physical 
tasks  to  be  accomplished  by  many  people,  and  as  a result,  it  may  be 
extremely  difficult  to  maintain  the  "integrity"  of  the  entire  system 
(Ref  13:42-44).  An  excellent  place  to  start  maintaining  system 
integrity  is  with  the  use  of  a complete  and  concise  software  require- 
ments definition.  As  with  any  problem  which  is  to  be  solved,  a better 
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solution  is  achieved  if  the  problem  structure  is 
Cisely  defined,  described,  and  understood. 


more  clearly  and  con- 


a rrhitectural  Philosophy 

The  word  architecture  implies  organisation.  At  first  glance,  a 
well  organised  software  systems  architectural  representation  might 
resemble  an  organisation  chart  for  some  large  corporation.  Thr. 
architectural  representation  also  implies  a management  hierarchy 
(Ref  40:25)  which  is  closely  associated  with  the  different  mformaUon 
levels  within  the  organisation  or  structure.  In  a software  system,  this 
hierarchical  structure  is  represented  by  the  purposeful  ordering  of  the 

pieces  or  parts  (modules)  which  make  up  the  system. 

A major  concern  of  the  software  engineer  or  designer  should  be 
th«  ordering  of  the  modular  structure  in  such  a way  as  to  reduce  com- 
plexity and  ease  the  processes  of  coding,  debugging,  testing,  integra- 
tion. and  operation  so  that  software  life-cycle  costs  will  be  reduced. 
The  design  phase  is  extremely  important.  Within  this  phase,  the  pre- 
liminary  design  should  result  in  an  identification  of  all  modules,  th.tr 
functional  descriptions,  their  interfaces,  the  hierarchical  structure 

■ H*ta  structure  relationships,  and  any 

of  those  modules,  the  associated  data  struct 

necessary  performance  requirements  (Ref  22:15). 

A recent  report  (Ref  38:5-6)  indicates  that  the  software  for  an 

operational  flight  program  used  in  a sophisticated  electro-optical 
sensor  system  was  designed  in  such  a way  that  its  architecture  will 
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not  allow  easy  modification  to  meet  changing  requirements.  In  order 
for  the  software  maintenance  and  support  operations  to  successfully 
meet  changing  requirements,  the  necessary  internal  software  design 
information  must  be  easily  transferable,  understandable,  and  com- 
plete (Ref  8:23-25). 

It  would  be  highly  desirable  to  use  an  appropriate  design  and 
self-documenting  methodology  to  provide  this  information.  It  should 
be  conducive  to  providing  an  improved  software  architectural  design 
which  can  more  easily  meet  changing  requirements  and,  in  addition, 
help  reduce  total  software  life-cycle  co6ts. 

The  Techn ique  of  Structured  Design 

Recently  several  software  design  techniques  have  received  the 
attention  of  software  engineers.  Hierarchy  plus  input-process -output 
(HIPO)  by  IBM  (Ref  17),  higher  order  software  (HOS)  by  Draper  Labs 
(Ref  lo),  top-down  by  Wirth  (Ref  39),  information  hiding  by  Parnas 
(Ref  27;  28),  Jackson's  method  (Ref  19),  composite  design  by  Myers 
(Ref  26),  and  structured  design  by  Constantine  (Ref  40)  are  design 
methodologies  currently  in  use.  The  latter,  structured  design  by 
Constantine,  will  be  briefly  discussed. 

Structured  design  is  a set  of  general  program  design  consider- 
ations and  techniques  used  to  make  coding,  debugging,  and  modifica- 
tion easier,  faster,  and  less  expensive  by  reducing  complexity  (Ref 
20:Sec  I,  1).  The  major  ideas  of  this  methodology  resulted  from 
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nearly  ten  years  of  research  by  Mr.  Larry  L.  Constantine.  He 
approached  Ins  research  from  a cost  standpoint  and  observed  (4tat 
some  designs  were  cheaper  than  others,  were  easier  to  implement, 
and  allowed  faster  and  easier  modifications  (Ref  34). 

A major  objective  of  structured  design  is  to  develop  a software 
system  of  modules  arranged  in  a hierarchical  manner  such  that  indi- 
vidual portions  can  be  evaluated,  implemented,  modified,  or  changed 

b 

without  affecting  the  rest  of  the  system  (Ref  29:42).  For  an  optimal 
design,  certain  principles  and  rules  are  used.  The  principles  of 
Coupling  (intermodular  connection  relationship)  and  Cohesion  (intra- 
modular  strength  relationship)  aim  for  low  or  loose  coupling  between 
modules,  and  high  individual  module  cohesion  (Ref  24:13).  In  addi- 
tion, rules  for  module  scope-of-efi'ect  and  scope -of-control  aid  the 
software  designer  in  achieving  this  objective.  A module's  scope-of- 
control  is  that  module  plus  all  subordinate  modules.  The  scope-of- 
effect  (of  a decision)  is  the  collection  of  all  modules  containing  any 
processing  that  is  conditional  upon  a decision.  For  any  given  deci- 
sion, the  scope-of-effect  should  be  within  the  scope-of-control  (Ref 
40:240). 

A data  flow  diagram  or  bubble  chart  is  used  (see  Appendix  B). 
The  bubble  chart  defines  the  required  order  of  data  transformation 
and,  according  to  Constantine,  should  not  show  control  flow,  timing, 
looping  or  machine  dependency.  The  bubble  chart  does  not  indicate 
the  modular  structure  (Ref  20:Sec  1,9).  The  focus  is  upon  major 
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streams  of  data  as  they  flow  from  external  input  to  external  output, 
and  the  transformation  processes  in  between  (Ref  24:15).  A structure 
chart  is  developed  from  the  bubble  chart  and  represents  the  hierar- 
chical relationships  of  the  modules  and  procedural  or  control  infor- 
mation (see  Appendix  Cl.  These  charts  are  used  in  a heuristic 
manner  to  document  design  refinement  and  evaluate  the  system  archi- 
tecture with  respect  to  the  principles  and  rules  previously  discussed. 

The  functional  orientation  of  structured  design  makes  it  partic- 
ularly appropriate  for  software  systems  which  might  experience 
changes  in  function  (Ref  24:1b),  possibly  like  those  associated  with 
operational  flight  software  in  a real-time  embedded  system.  Modifi- 
cations which  involve  additional,  augmented,  or  deleted  functions  are 
relatively  straightforward  (Ref  24:16)  where  structured  design  has 
been  used. 

Summary 

This  chapter  expressed  a concern  for  software  requirements 
and  design  engineering  with  a goal  toward  purposeful  software  system 
structuring  and  the  use  of  a method  for  accomplishing  that  structuring. 
The  traditional  approach  of  many  software  practitioners  (and  man- 
agers) in  going  directly  from  the  problem  (system  specification)  to 
the  coding  phase  is  highly  undesirable  and  costly.  The  need  for  a 
complete,  unambiguous,  written,  and  mutually  agreed  upon  require- 
ments definition  is  highly  desirable.  A software  architecture  which 
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easily  allows  future  changes,  is  easily  understood,  and  aids  in  reduc- 
ing software  life-cycle  costs  associated  with  a system  is  also  desir- 
able. Present  day  Air  Force  software  is  very  expensive.  Finally, 
Structured  Design  by  Constantine  is  a software  design  methodology 
that  makes  coding,  debugging,  and  modification  easier,  faster,  and 
less  expensive.  These  attributes  are  highly  desirable  lor  Air  Force 
computer  software.  Prior  to  discussing  the  application  of  design 
techniques,  the  PAVE  TACK  OFP  will  be  briefly  described. 
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III.  I'lu-  l’A\  I TACK  Operational 

1 1 1^:  I it  Program 

hit  todm  lion 

l ias  chapter  brietly  tl«* ?. *.  rilu-K  the  iiporation.il  flight  program 
tor  a current  Air  Force  sysirm  named  I’AN'K  TACK.  li moral  infor- 
matioii,  subsystem  intort.u  on  and  the  executive  structure  art*  dis- 
o un sod. 

Clone  i a I 

1’AVK  TACK  is  a name  given  to  an  advanced  day/night  electro- 
optical,  pod-mounted  attack  and  surveillance  system  intended  to 
improve  weapon  delivery  capability.  The  FAYF  TACK  pod  can  be 
centerline  mounted  or  located  on  any  stores  station  of  a particular 
fighter  aircraft.  In  addition  to  supporting  avionics  and  power  con- 
version equipment,  the  pod  contains  a digital  computer  (Kef  25:F>0). 
Within  the  computer  the  OKI*  performs  significant  mission  functions. 

The  1'AVK  TACK  OF l’  interfaces  with  the  pod  to  perform  target 
search  and  tracking  functions.  It  also  interfaces  with  the  aircraft 
computer  (serial  digital  interface)  for  the  input  of  navigation  and  aim- 
point  data  and  the  output  of  navigation  correction  updates.  Computa- 
tions are  performed  which  in  turn  generate  signals  to  the  I’AVK  TACK 
stabli/.ed  sight  subsystem  to  assist  m acquiring  and  tracking  targets, 
laser  information  (e.g.  slant  range),  operator  signals  te.  g.  tracking 
control  handle),  and  electro-optical  sightline  angular  data  are 
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processed  by  the  OFP  to  provide  data  tor  updating  aircraft  navigation 
and  weapon  delivery  functions  (Ref  7 :Sec  HI,  1). 
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The  OFP  resides  in  the  flight  computer  memory.  Under  control 
of  the  stored  OFP,  a conversion  unit  accepts  analog  data  from  the  pod 
and  avionics  systems  and  converts  this  data  for  use  by  the  digial  com- 
puter. Alter  processing  the  data,  some  outputs  of  the  computer  are 
converted  to  appropriate  analog  signals.  Other  data  is  available  or 
produced  in  the  form  of  "discretes"  which  are  special  words  in  com- 
puter memory.  Each  word  consists  of  bits,  each  of  which  represent 
a specific  status  (e.  g.  inhibit  laser,  system  failure,  hand-control 
switch,  and  so  forth).  For  further  details  on  the  OFP,  the  reader 
may  refer  to  references  4,  5,  o,  7,  15,  18,  and  38. 

Subsystem  Interfaces.  It  is  necessary  to  synchronize  the  OFP 
functions  with  those  being  performed  by  subsystems,  and  there  are  a 
number  of  different  interfacing  loops  involved.  The  three  interfacing 
loops  are  the  operator  loop,  the  pod/OFP  loop,  and  the  aircraft  com- 
puter/OFP  loop.  The  functional  subsystem  interfaces  for  the  OFP 
may  be  seen  in  Fig.  2. 

PAVE  TACK's  primary  time tion  is  target  acquisition  and  track- 
ing. In  the  operator  loop,  this  function  is  controlled  by  the  aircrew. 

Analog  thumb  tracker  inputs  (i.  e.  the  tracking  control  handle)  allow 
the  aircrew  to  control  the  line  of  sight  (LOS)  of  the  forward  looking 
infrared  (FI  IR)  detector  and  laser  in  the  pod.  Feedback  to  the  air- 
crew is  through  a CRT  display  which  is  controlled  by  software  and  f 
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Fig.  2.  PAVE  TACK  OFP  Subsystem  Interfaces  (Ref 
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hardware.  The  interactive  pod/OFP  loop  exists  between  the  pod 
subsystems  and  the  - . P.  The  pod  provides  analog  LOS  position  and 
rate  data  to  the  OFP,  while  the  OFP  provides  analog  LOS  position 
control  as  a function  of  errors  and  control  inputs.  Hardware  and 
software  parameters  maintain  loop  stability.  The  primary  purpose 
of  the  aircraft  computer/OFP  loop  is  to  provide  aircraft  computer 
navigation  and  aimpoint  data  to  the  OFP.  This  loop  is  interconnected 
with  the  operator  interface  through  the  aircraft  computer. 

Executive  Structure.  The  executive  handles  the  timing  and  task 
sequencing  of  the  entire  OFP.  hi  addition,  the  executive  is  responsi- 
ble for  assuring  that  the  program  resumes  without  "impurity"  where 
it  left  off  after  a timing  or  data  interrupt  lias  occurred. 

The  executive  control  module  of  the  PAVE  TACK  OFP  consists 
of  three  main  routines:  the  power  interrupt  module,  the  level- 1 
interrupt  routine,  and  the  level-0  interrupt  routine.  The  power  inter- 
rupt module  performs  the  initial  condition  settings  for  the  OFP  after 
the  occurrence  of  the  power-up  interrupt  or  after  Lhe  completion  of  a 
system  built-in  test  (BIT). 

The  level-  1 routine  controls  the  basic  timing  of  the  OFP  pro- 
gram execution.  A programmable  timer  (counter)  is  set  to  generate 
a level-1  timer  interrupt  every  8.33  milliseconds.  Whenever  this 
timer  interrupt  is  generated,  the  executive  control  portion  of  the 
level- 1 routine  is  entered.  Processing  consists  of  a mainloop  cycle 
of  25  milliseconds,  a fastloop  cycle  of  8.33  milliseconds,  and  slow  f 
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cycle  of  100  milliseconds  and  1 second.  The  fastloop  performs  the 
rate  aiding  and  image  derotation  angle  extrapolation  computations  in 
order  to  provide  the  rate  aiding  signals  and  de rotation  angle  output 
at  the  rate  of  120  hertz.  The  slow  cycles  include  a call  to  a subrou- 
tine vvluch  flashes  the  laser  transmitter-on  indicator  on  the  CRT  at 
the  rate  of  five  times  a second  whenever  the  laser  transmitter  is  on. 
The  other  portion  of  the  s low  cycle  consists  of  the  CRT  display  output 
processing. 

The  main  processing  of  the  PAVE  TACK  OFF  is  performed 
every  Z5  milliseconds  when  the  executive  calls  the  mainloop  module. 
The  start  of  analog  data  input  conversion  is  initiated  by  the  executive 
immediately  before  the  execution  of  the  mainloop.  The  mainloop  may 
be  interrupted  by  the  level- 1 timer  interrupts.  The  executive  checks 
to  see  whether  the  slow  cycle  processings  are  required,  calls  the 
slow  cycle  processings  or  sets  the  flags  for  slow  cycle  processings 
when  required,  and  returns  to  the  processing  interrupted.  After  a 
cycle  of  the  mainloop  processing  is  completed,  control  is  returned 
to  the  executive. 

The  executive  also  calls  the  one  hertz  processes  when  required 
and  starts  or  continues  a BIT  software  program  which  is  performed 
on  a time  available  basis.  This  program  is  called  the  running  BIT 
program,  and  it  performs  limited  self-tests  of  the  CPI',  memory, 
input /output,  and  pod  subsystems.  The  level-0  interrupt  routine 
services  analog  data  conversion  and  laser  input  processing  when  the 
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signal  converter  interrupts  are  generated.  The  OFP  executive  con- 
trol program  is  a synchronizing  executive.  The  level-0  interrupt 
routine  services  asynchronous  external  inputs  at  a higher  priority 
level  than  the  executive  program. 

Summary 

This  chapter  presented  a brief  description  of  an  operational 
flight  program  for  a current  Air  Force  pre -operational  avionic  sys- 
tem called  PAVE  TACK.  General  information,  subsystem  interfaces 
and  the  executive  structure  were  discussed. 
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IV.  Application  of  Design  Techniques 

Introduction 

This  chapter  describes  the  results  of  applying  several  design 
tecliniques  to  the  PAVE  TACK  OFP.  The  initial  approach  attempting 
to  apply  the  structured  design  methodology  is  discussed.  Included 
are  some  of  the  problems  that  were  encountered.  Finally,  the 
revised  design  approach,  as  a result  of  the  problems  encountered 
during  the  initial  approach,  is  described,  and  several  design  tech- 
niques are  discussed. 

Initial  Approach 

Objective.  For  the  initial  approach,  the  structured  design 
methodology  was  to  be  applied  to  the  entire  PAVE  TACK  OFP  require- 
ment. After  a reasonable  amount  of  requirements  familiarization 
time,  the  draft  Part  I software  specification  (Ref  4)  was  used,  as  it 
should  be,  for  the  basis  of  the  software  design.  It  was  anticipated 
that  this  would  be  the  same  design  starting  point  for  an  avionics 
software  engineer/contract  monitor.  The  operation  of  the  OFP, 
developed  with  structured  design,  would  be  a "black  box"  equivalent 
to  the  current  software.  However,  the  internal  software  architecture 
of  the  new'  design  would  be  different,  and  the  benefits  of  this  type  of 
design  were  previously  discussed  in  Chapter  II.  Transform  analysis 
was  used  to  start  the  design  process. 
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Application  of  Transform  Analysis.  Constantine  defines  Trans- 
form Analysis,  or  transform-centered  design,  as  a strategy  which 
identifies  the  primary  processing  functions  (transform  center)  of  the 
desired  software  system,  the  high-level  inputs  (afferent  data  ele- 
ments) to  those  functions,  and  the  high-level  outputs  (efferent  data 
elements)  from  those  functions  (Ref  40:254).  The  concepts  behind 
the  strategy  of  a structured  design  were  briefly  described  in  Chapter 
U.  The  major  steps  of  transform  analysis  are: 

1.  Restate  the  "problem"  as  a data  flow  diagram  (bubble 

i chart). 

2.  Identify  the  afferent  and  efferent  data  elements  on  the 

i bubble  chart. 

i 

3.  Perform  first  level  factoring  to  obtain  an  initial  high-level 
structure  chart. 

i 

I 

4.  Using  this  structure  chart,  factor  tire  afferent,  transform, 

1 

and  efferent  branches. 

5.  Complete  the  final  structure  chart  by  noting  any  departures 
from  the  structure  chart  obtained  in  the  previous  step. 

Departures  refer  to  changes  resulting  from  a design  trade-off 
analysis  of  scope-of-effect,  scope-of-control,  the  principles  of 
coupling  and  cohesion,  and  any  a priori  knowledge  of  particular 
"real-world"  effects  on  a proposed  design.  As  mentioned  in  step 
one,  the  transform  analysis  process  starts  with  the  development  of 
a bubble  chart. 
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Attempting  to  start  the  initial  development  of  a system- level 


bubble  chart  tor  the  PAVE  TACK  OFF  was  not  easy.  The  draft  Part 
I specification  (Ref  4)  did  not  necessarily  indicate  how  data  for  the 
OFP  was  related  to,  or  oriented  (e.g.  task,  operator  selected  mode, 
etc.)  for  vise  by  the  desired  software.  A system-level  bubble  chart 
should  consist  of  all  major  inputs,  all  major  outputs,  and  all  appro- 
priate data  transformations  between  the  two  types  of  data.  However, 
due  to  lack  of  written  direction  (draft  Part  1 specification),  the  com- 
plexity of  the  design  problem  slowly  became  apparent.  It  might  be 
possible  to  orient  the  data  for  the  bubble  chart  by  task  (or  mission 
related  function),  data  classes  (discrete  or  analog),  mode  ^search), 
interrupt  levels  or  some  combination  of  these.  Upon  closer  exami- 
nation, it  appeared  as  though  a task  and/or  mode  data  orientation 
might  be  the  best  direction  to  take. 

However,  a change  in  applying  transform  analysis  to  the  entire 
OFP  hail  to  be  made  in  order  to  allow  the  study  to  proceed.  With 
respect  to  the  entire  OFP,  processing  outside  the  mainloop  appeared 
to  involve  too  much  timing  and  control.  A basis  in  applying  a bubble 
chart  is  to  avoid  timing  and  control.  Therefore,  it  was  decided  that 
a bubble  chart  would  not  be  directly  applicable  to  the  executive  and 
other  associated  functions  outside  of  the  OFP  mainloop.  As  a result, 
the  decision  was  made  to  apply  the  transform  analysis  steps  to  the 
OFP  mainloop  since  most  of  the  operational  airborne  functions  are 

performed  there  (Ref  38:A1).  ® : 
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Several  unsuccessful  attempts  were  made  to  create  a mainloop 
bubble  chart.  One  particular  attempt  is  worth  noting.  Realizing  that 


the  mainloop  performed  several  functions,  the  idea  of  generating 
subsets  of  bubble  charts  (bubble  chunks),  which  would  later  be  com- 
bined, seemed  appealing.  Bubble  chunks  were  created  for  several 
sub-functions  such  as  ACQUIRE,  SNOWPLOW,  TERRAIN  MONITOR 
and  NAVIGATION  cueing.  The  bubble  chunks  were  combined  to  form 
the  bubble  chart  associated  with  sightline  control  during  the  search/ 
acquire  function.  Although  the  idea  of  using  bubble  chunks  is  a valid 
technique  (Ref  20:Sec  11,26-31),  it  did  not  work  well  in  this  case. 

The  result  was  a very  poor,  if  not  invalid,  bubble  chart.  The  bubble 
chart  was  extremely  cluttered,  had  interfering,  crossing  data  flow 
lines  (not  allowed),  was  inconsistent  in  several  areas  (e.g.  undesir- 
able differences  in  data  stream  names),  and  tended  to  show  some 
control  (not  allowed).  Later  the  reason  for  this  result  will  become 
apparent. 

After  much  time  was  consumed  experiencing  several  such 
"blind  alleys,  " the  final  Part  1 software  specification  tRef  5)  became 
available  and  proved  to  be  helpful.  The  QFP  functional  summary 
now  listed  the  major  tasks  to  be  performed  (Ref  5:Sec  I,  1-2)  rather 
than  a description  of  the  OFP  "modules"  (Ref  4:2).  Normally  a 
complete  description  (including  interfaces)  of  OFP  mainloop  modules 
would  exist  after  the  preliminary  design  as  a result  of  an  entire 
application  of,  for  example,  th.  design  techniques  presented  in  this 
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chapter.  The  following  major  tasks  associated  with  the  OFP  main- 


loop  were  extracted  (verbatim)  from  the  functional  summary  list 
(Kef  5:Sec  I,  1-2): 

1.  Provide  signals  to  the  PAVE  TACK  sightline  control 
electronics  to  assist  in  acquiring  and  tracking  targets. 

2.  Provide  velocity  trim  and  navigation  update  data  to  the 
aircraft  computer.  (Clarifying  Note:  The  navigation 
update  actually  consists  of  velocity  and  range  trim  data.) 

3.  Inhibit  laser  operations  under  specified  conditions. 

4.  Provide  image  derotation  and  focusing  signals  to  the 
AN/AAQ-0  Infrared  Detecting  Set. 

The  major  tasks  listed  above  served  as  the  first  vague  indication  of 
actual  mainloop  requirements  as  per  a Part  1 specification. 

The  final  Part  l specification  also  gave  very  brief  summaries 
of  the  mainloop  major  tasks  listed  above  (Ref  5:Sec  1,2-7).  The 
summaries  were  helpful  with  respect  to  task  familiarization.  It  was 
reasonable  to  expect,  from  a designer's  point  of  view,  some  written 
description  of  any  precedence  relationship  associated  with  the  set  of 
tasks  comprising  the  mainloop.  It  was  obvious  from  studying  the 
specification  that  some  tasks  or  actions  were  required  prior  to 
others  (e.g.  input  specific  data  at  start  of  mainloop,  or  perform 
coordinate  transformation  of  inertial  - to- sightline  information). 
However,  precedence  information  of  a level  of  detail  sufficient  for 
this  design  study  was  not  found. 


A final  attempt  was  made  to  apply  transform  analysis  to  the 
OFP  mainloop.  Major  functions  were  analyzed.  During  the  attempt 
to  generate  a bubble  chart,  it  was  realized  that  no  afferent  or  efferent 
data  elements  could  be  found  between  the  major  tasks.  In  fact,  each 
major  task  actually  functioned  as  an  input-process -output  tlPO) 
scheme.  That  is,  each  major  function  investigated  for  the  mainloop 
could  be  considered  a small  application  program  in  itself.  This 
explained  why  previous  bubble  chart  attempts  (e.  g.  using  bubble 
chunks)  did  not  succeed.  With  this  realization,  it  became  obvious 
that  the  approach  to  the  structured  design  investigation  would  have 
to  be  modified. 

Revised  Approach 

Objectives . For  the  revised  approach,  several  design  tech- 
niques were  applied  to  the  PAVE  TACK  OFP  mainloop  requirement. 
The  final  Part  I specification  (Ref  5)  was  used  in  the  same  manner 
previously  discussed  (initial  approach  objective).  The  design  tech- 
niques were  applied  to  several  sections  of  the  OFP  mainloop,  but 
procedures  related  to  each  technique  are  carried  out  only  far  enough 
to  show  the  avionics  software  engineer /contract  monitor  "how  to  get 
started"  on  a design.  Finally,  a software  design  is  subjective,  and 
naturally,  may  vary  from  one  designer  to  another. 

Finite-State  Technique.  For  the  purposes  of  this  study,  the 
finite-state  technique  is  defined  as  a method  that  uses  a state 
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diagram  to  represent  a specific  algorithm's  control  flow.  The  state 
diagram  is  made  op  of  nodes  and  directed  links  which  represent  con- 
trol of  the  OFF  mainloop  operational  airborne  functions  or  tasks. 

The  nodes  are  represented  by  circles.  The  directed  links  ii.  e.  edges) 
between  nodes  are  represented  by  an  arc. 

The  teclinique,  as  used  here,  has  been  slightly  modified  from 
current  finite-state  autonoma  methods  tRef  114:22-27;  1 1:221-239). 

In  this  study,  each  node  represents  a task.  Since  each  task  within 
the  OFF  mainloop  has  previously  been  defined  as  an  1FO  scheme,  no 
data  is  passed  between  tasks  at  this  level  estate  diagram)  of  observa- 
tion. Froper  sequencing  of  control  from  one  OFF  mainloop  task  to 
another  is  of  prime  importance  at  this  stage  of  design.  In  this 
respect,  the  technique  permits  a better  understanding  of  the  algo- 
rithm's control  structure  by  using  an  appropriate  "level  of  observa- 
tion" and  reducing  superfluous  detail. 

For  the  PAVE  TACK  OFP  mainloop,  a particular  control 
relationship  (i.e.  search,  cue  or  track  mode  selected  by  the  opera- 
tor) was  known  (Ref  5:Sec  III,  65;  Sec  XX,  9-10)  at  the  start  of  each 
mainloop  execution.  This  relationship  was  used  to  direct  control  to 
the  next  task  in  the  mainloop.  This  is  possible  because  the  maximum 
mainloop  execution  rate  is  forty  hertz,  and  the  mode  does  not  change 
during  any  particular  mainloop  cycle.  Although  the  mainloop  is 
pre- emptable,  task  execution  resumes  when  the  request  causing  an 

interrupt  is  satisfied.  For  example,  an  interrupt  generated  for  1 
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laser  data  input  pre-empts  an  "in-process"  task  in  the  mainloop. 
After  the  laser  data  has  been  "processed,  " the  interrupted  task  in 
the  mainloop  resumes  its  processing.  The  control  relationship, 
defined  above,  works  in  a satisfactory  manner  for  this  application  of 
the  finite-state  technique  since  the  mainloop  can  be  considered  a 
closed  sub-task  system  (mainloop  is  part  of  the  executive).  That  is, 
the  mainloop  contains  a unique  initial  task  (adjust  raw  input  data  for 
OFP  use)  and  a unique  terminal  task  (adjust  raw  input  data  for  OFP 
use)  and  a unique  terminal  task  (adjust  processed  data  for  output). 
Obviously,  execution  of  the  mainloop  is  considered  complete  when  all 
applicable  tasks,  depending  on  the  control  relationship,  have  been 
processed  including  the  initial  and  terminal  tasks. 

The  control  relationship  previously  discussed,  and  results  of 
further  analysis  of  the  mainloop  requirements  (Ref  5:Sec  III,  65-68) 
were  used  to  apply  the  finite-state  technique.  The  resulting  state 
diagram  is  shown  in  Fig.  3,  and  a description  of  next-state  transi- 
tions by  mode  (search,  cue  or  track)  are  shown  in  Table  I.  This 
type  of  table  may  be  helpful  during  the  coding  phase,  but  can  be 
quite  large  depending  on  the  particular  OFP  requirements.  In  Fig. 

3,  node  one  is  the  initial  task  and  node  eight  is  the  terminal  task  of 
the  OFP  mainloop.  Node  six  (Perform  Target  Operations)  is  in  an 
abstract  form  in  order  to  simplify  the  state  diagram.  It  consists  of 
many  sub-tasks  or  functions,  some  of  which  will  be  shown  later  in 
this  chapter  (see  Transform/Transaction  Analysis). 
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M. unloop  State  Transitions  by  Mode 
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If  larger,  more  complex  task  systems  are  required,  the 
designer  can  vise  a more  rigorous  approach.  A stricter  task  notation 
for  chains  and  precedence  may  he  used.  If  the  designer  requires 
this  type  of  detail,  any  good  text  that  uses  graph  theory  applied  to 
operating  systems  may  be  used.  See  reference  14. 

The  state  diagram  may  be  refined  in  any  appropriate  manner, 
and  verified  by  checking  the  tasks  of  the  diagram  against  the  func- 
tional design  requirements  until  the  requirements  are  met.  Desired 
levels  of  detail,  clarity  and  completeness  may  be  achieved.  It  is 
important  that  the  state  diagram  directly  reflects  the  algorithm 
structure  and  meets  the  written  design  requirements.  Once  the  soft- 
ware designer  completes  this  step  (application  of  the  finite-state 
technique),  the  technique  could  be  applied  (if  warranted)  to  another 
single  "task"  within  the  state  diagram  just  developed  (e.g.  Perform 
Target  Operations).  Developing  state  diagrams  at  more  than  one 
level  allows  design  refinement.  Each  successive  level  would  obvi- 
ously contain  a greater  amount  of  detail.  In  addition,  the  techniques 
which  follov.  can  also  be  applied  to  a single  task  vuitil  the  entire  OFF 
mainloop  design  is  complete. 

Transform  Analysis  Technique.  For  the  revised  approach, 
Constantine's  version  of  transform  analysis  (Ref  40:254-300)  was 
modified.  The  technique  was  extended  to  include  iterations  between 
the  bubble  and  structure  charts  (Ref  20:Sec  11,  1-36).  The  modified 
transform  analysis  technique  permits  successive  design  refinement. 
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The  major  steps  are: 

1.  Restate  the  "problem"  as  a data  flow  diagram  (bubble  chart). 
This  is  called  the  "first-cut"  bubble  chart. 

Z.  Identify  the  afferent  and  efferent  data  elements  on  the 
bubble  chart. 

3,  Develop  a fully  factored,  "l'irst-cut"  structure  chart. 

■4.  Using  the  basic  principles  of  coupling,  cohesion,  seope-of- 
efl'ect,  and  scope-of-control,  analyze  the  first-cut  structure 
chart. 

5.  Using  the  results  of  the  analysis,  rearrange  any  modules  as 
necessary,  and  recheck  the  analysis  as  necessary.  When 
the  analysis  is  complete,  the  resulting  structure  chart  is 
called  the  "intermediate"  structure  chart. 

t>.  From  the  intermediate  structure  chart,  develop  a new 
(revised)  bubble  chart.  This  is  referred  to  as  the  inter- 
mediate bubble  chart. 

7.  Revise  the  transform,  and  afferent  and  efferent  data  ele- 
ments on  the  bubble  chart  as  necessary.  This  is  called  the 
"final"  bubble  chart. 

8.  Lastly,  develop  the  final  structure  chart  from  the  final 
bubble  chart. 

In  any  analysis  of  a bubble  chart,  it  should  be  remembered  that  the 
bubble  chart  may  be  considered  a graphical  representation  of  the 
problem's  requirement  definition.  Obviously  each  bubble  chart 
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should  be  checked  against  the  written  requirements  l'or  misinterpre- 
tation of  those  requirements  or  any  other  errors  (e.  g.  an  incorrectly 
named  data  element).  The  final  structure  chart  represents  the 
design,  and  the  chart  should  reflect  the  problem  structure. 

Transform  Analysis  will  be  applied  to  the  "Perform  IDS  Image 
Derotation"  task  in  the  mainloop  state  diagram  shown  in  Fig.  3. 

Some  of  the  OFF  mainloop  tasks  are  triv  ial  (e.  g.  "Setup  IDS  Focus"), 
while  others  are  more  complex  (e.g.  "Preprocess  Raw  Data").  How- 
ever, the  infrared  detector  set  (IDS)  Image  Derotation  task  is  simple 
to  understand.  Operator  hand  control  data  and  electro-optical  (EO) 
gimbal  data  are  used  to  generate  certain  derotation  data  which  per- 
mits the  IDS  to  perform  the  image  de rotation  function.  When  a 
target  has  been  acquired  (with  respect  to  the  aircraft  using  PAVE 
TACK),  the  target  image  can  be  displayed  (in  the  cockpit)  in  a nor- 
mal and  upright  manner,  and  thus  enhance  recognition  of  a target. 
This  type  of  image  display  is  accomplished  if  the  operator  selected 
the  "Horizontal  Natural"  display  mode.  If  this  type  of  image  display 
is  not  selected,  the  target  image  is  displayed  such  that  the  vectored 
component  of  aircraft  velocity  is  upward  relative  to  the  display 
(Ref  5:SecI,  6). 

After  an  extensive  analysis  of  the  requirements  for  the  IDS 
image  derotation  task,  a first-cut  bubble  chart  was  completed,  and 
the  afferent  and  efferent  data  elements  were  identified  as  shown  in 
Fig.  -1.  The  placement  of  the  afferent/el'ferent  "cuts"  may  vary 
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IDS  Image  Derotation  First-Cut  Bubble  Chart 


slightly  from  one  designer  to  another.  The  central  transform  for 
this  problem  lies  between  the  afferent/efferent  cuts.  Within  the 
identified  central  transform,  two  main  functions  are  performed. 

Raw  hand  control  data  is  derotated  by  using  the  derotation  angle  which 
is  either  a preset,  or  calculated  and  modified  angle.  The  modified 
derotation  angle  is  derived  by  applying  predetermined  angle  limits  to 
the  computed  angle.  The  computed  angle  is  obtained  from  the  electro- 
optical  gimbal  data  (roll,  pitch  and  yaw  sine/cosine  gimbal  informa- 
tion). For  the  second  function,  the  derotation  angle  rate-of-change 
increment  is  computed  using  the  modified  derotation  angle  and  the 
status  of  the  horizontal-natural  mode  selected  by  the  operator.  The 
horizontal-natural  status  and  the  w ide -field -of -view  (WFOV)  status 
are  obtained  from  specific  discrete  input  words  (D1WX)  in  memory. 
The  WFOV  status  is  used  to  update  the  PAVE  TACK  pod  status.  The 
WFOV  status  may  also  be  used  to  scale  (a  magnification  function  used 
for  cockpit  display)  the  derotated  hand  control  data. 

The  bubble  chart.  Fig.  4,  can  be  used  to  verify  the  designer's 
interpretation  of  the  problem  by  comparing  it  to  the  requirements 
definition  (Part  I specification).  If  necessary,  the  bubble  chart  may 
be  revised  to  conform  to  the  problem  requirements  as  they  are  under- 
stood at  this  point  in  time.  When  the  designer  is  satisfied  with  the 
first-cut  bubble  chart,  the  first-cut  structure  chart  can  be  developed. 

The  first-cut  structure  chart  shown  in  Fig.  5 was  developed 
directly  from  the  first-cut  bubble  chart  with  the  data  and  control 
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Fig.  5.  IDS  Image  Derotation  First-Cut  Structure  Chart 


arrows  added.  Any  decisions  within  the  hierarchical  structure  are 


also  shown.  The  modules  are  annotated  with  descriptive  phrases 
rather  than  single  names.  Table  II  lists  the  input  and  output 
parameters  ol’  the  first-cut  structure  chart.  Any  control  parameters 
are  underlined. 

The  software  engineer /contract  monitor  may  not  want  to  use  a 
descriptive  phrase  for  each  module.  As  an  alternative,  singular 
verbs  can  be  used  which  characterize  each  module's  function  (Ref  40: 
273-277).  For  example,  the  following  names  could  be  applied  to  the 
second-level  modules  (by  number)  of  Fig.  5: 


1. 

C.ETHORZSTAT 

b. 

DEROTHANCONTL 

y 

4m  • 

GETHANCONTLDAT 

7. 

COMPANC.ROCI 

3. 

GETSETANG 

8. 

PUTHANDAT 

4. 

GET  MO  DANG 

9# 

PUTANGDAT 

5. 

GETVIEWSTAT 

10. 

PUTINCREDAT 

The  designer  has  the  choice  of  using  either  method  of  module  identi- 
fication.  Regardless  of  the  method  chosen,  its  use  should  be  con- 
sistent for  each  structure  chart. 

The  first-cut  structure  chart  was  analyzed.  The  structure  in 
Fig.  5 is  fully  factored,  and  has  a depth  of  four.  The  fan-in  for  all 
modules  of  the  second  through  fourth  levels  is  one.  The  fan-out  or 
span-of-control  of  modules  in  the  same  levels  ranges  from  one  to 
three.  Note  that  the  fan-out  for  the  level-one  module  is  ten,  which 

might  be  considered  slightly  high.  This  in  turn  makes  the  I 

j 
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Table  II 

First  Cut  Structure  Chart  Parameters 


Module 

Input 

Output 

1 

— 

Horizontal-Natural  Status 

2 

— 

Hand  Control  Coordinates 

3 

— 

Preset  Derotation  Angle 

4 

— 

Modified  Derotation  Angle 

5 

— 

WFOV  Status 

6 

Hand  Control  Coordi- 
nates, Preset  Derota- 
tion Angle,  Computed 
Derotation  Angle 

Derotated  Hand  Control 
Coordinates 

7 

Modified  Derotation 

Angle,  Horizontal- 
Natural  Status 

Computed  Rate  of  Change 
Increment,  Preset  Rate  of 
Change  Increment 

8 

WFOV  Status  Flag, 
Derotated  Hand  Control 

Coordinates 

— 

9 

Derotation  Angle 

— 

10 

Computed  Rate  of  Change 
Increment,  Preset  Rate 
of  Change  Increment 

— 

11 

— 

DIW  4 

12 

DIW  4 

Horizontal -Natural  Status 

13 

— 

Hand  Control  Coordinates 

14 

— 

Preset  Derotation  Angle 

15 

— 

Computed  Derotation  Angle 

16 

— 

De rotation  Angle  Limits 
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Table  II  ( Continued) 


— 

Input 

Output 

Computed  Derotation 
Angle,  Derotation  Angle 
Limits 

Modified  Derotation  Angle 

— 

DIW  2 

diw  z 

WFOV  Status 

WFOV  Status 

De rotated  Hand  Control 

Coordinates 

Scaled  Derotated  Hand 

Control  Coordinates 

Scaled  Derotated  Hand 

Control  Coordinates 

— 

Derotation  Angle 

— 

Computed  Rate  of  Change 
Increment,  Preset  Rate 
of  Change  Increment 

— 

— 

EO  Gimbal  Angular  Data 

EO  Gimbal  Angular  Data 

Computed  De  rotation  Angle 

Pod  Status 

WFOV  Status,  Pod 

Status 

Modified  Pod  Status 

Modified  Pod  Status 

— 

ote:  Control  Information  is  underlined 


scope-of-control  eleven  for  the  first  level  module.  The  scope-of- 
control  is  four  for  modules  four,  five  and  twenty;  three  for  modules 
one,  eight  and  fifteen;  and  h\o  for  all  applicable  remaining  modules. 
There  are  two  decisions  shown  on  the  structure  chart.  One  decision 
is  in  the  first  level  module  and  involves  modules  three  and  four. 

The  data  (derotation  angle)  obtained  from  these  modules  is  used  for 
processing  in  modules  six  and  seven  which  are  also  invoked  by  the 
first  level  module.  Therefore,  the  scope-of-effect  for  this  decision 
is  within  the  scope-of-control.  The  other  decision  is  located  in 
module  eight  (second  level),  and  its  scope-of-effect  is  within  the 
scope-of-control  for  that  module.  Finally,  note  that  modules  two 
and  three  are  truly  afferent,  and  modules  nine  and  ten  are  truly 
efferent  by  definition. 

To  complete  the  analysis,  coupling  and  cohesion  of  all  modules 
was  examined.  The  procedures  used  were  applied  to  all  modules  on 
the  first-cut  structure  chart.  The  analysis  of  module  coupling  (Ret 
40:llt>-142;  20:33-53)  required  the  use  of  Fig.  b and  Table  11.  For 
example,  modules  one,  eleven  and  twelve  are  data  coupled.  On  the 
other  hand,  module  eight  is  control  coupled.  Finally,  the  cohesion 
of  all  modules  in  Fig.  5 was  examined.  The  analysis  required 
familiarization  with  cohesion  type-definitions  (Ref  40:143-186;  2o: 
19-31).  A sentence  describing  the  purpose  of  each  module  was 
written.  Each  sentence  was  analyzed  (Ref  40:171-173;  20:28-30). 

For  example: 


41 


1.  Moduli’  one:  The  purpose  of  this  module  is  to  obtain  the 
"current"  horizontal -natural  status. 

2.  Module  eleven:  The  purpose  of  this  module  is  to  read 
discrete  input  word  fou*  (DIIV4)  from  memory. 

y 

3.  Module  twelve:  The  purpose  of  this  module  is  to  find  the 
horizontal -natural  status  embedded  within  P1W4. 

From  these  "simple"  sentences,  it  is  obvious  that  each  of  these 
modules  is  functionally  cohesive.  Examining  each  module's  coupling 
and  cohesion  in  this  analysis  enables  the  designer  to  investigate 
alternative  structures  in  an  attempt  to  produce  an  intermediate 
structure  chart. 

An  example  of  investigating  structure  chart  alternatives  is  illus- 
trated in  Figures  6 and  7.  Figure  t>  shows  a section  or  one  afferent 
branch  that  was  easily  obtained  from  Fig.  3.  Note  that  the  decision 
in  the  first  level  module  of  Fig.  5 is  "high"  in  the  structure.  It  was 
desirable  to  move  that  decision  further  down  into  the  structure  (a 
lower  level).  By  moving  modules  three  and  four  down  to  the  third 
level  subordinate  to  a "new"  single  module  ("OBTAIN  DEROTATION 
ANGLE")  in  the  second  level,  the  afferent  branch  in  Fig.  b is 
obtained.  A problem  created  by  this  alternate  afferent  branch  is  that 
the  superordinate  module  is  control  coupled  to  the  first  level  module 
in  Fig.  5.  It  is  not  necessarily  desirable  to  go  from  data  coupling  to 
control  coupling,  but  in  this  case  since  the  "Horizontal-Natural 
Status"  is  passed  to  the  "OBTAIN  DEROTATION  ANG1  E"  module  to 
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affect  tin’  decision,  tin'  control  coupl my,  problem  can  be  remedied. 

The  revised  alternate  afferent  branch  is  shown  in  Fig.  7. 
Module  one  ("tiFT  HOU/’.  NAT  STATUS"),  an  atterent  module  from 
Fig.  F>,  is  moved  to  the  subordinate  position  as  shown  in  Fig.  7. 

The  "OUTAIN  PF  ROTATION  ANOl  1'"  module  is  now  data  coupled. 
The  modules  on  the  second  and  third  levels  of  Fig.  7 are  still  func- 
tionally cohesive.  Using  this  method  of  developing  alternative 
branches  for  the  structure  chart  is  useful  since  smaller  sections  of 
the  structure  chart  are  easier  to  understand  and  analyse.  It  helps 
the  designer  to  develop  the  intermediate  structure  chart,  which  is  the 
next  suggested  design  step.  However,  to  arrive  at  .in  acceptable 
intermediate  structure  chart,  the  designer  must  perform  an  analysis 
such  as  that  performed  on  the  first-cut  structure  chart. 

After  several  alternate  revised  first-cut  structure  chart 
branches  were  analyzed,  an  intermediate  structure  chart  was  com- 
pleted. For  simplicity,  the  abbreviated  intermediate  structure  chart 
(no  data  or  control  arrows  and  no  module  numbers)  is  shown  in  Fig. 

S.  An  analysis  of  the  intermediate  structure  chart  was  accom- 
plished in  a similar  manner  as  that  described  for  the  first-cut 
structure  chart.  The  completion  of  this  structure  chart  permits  the 
development  of  the  next  bubble  chart. 

An  intermediate  bubble  chart  was  developed  as  shown  in  Fig.  *). 
It  was  verified  against  and  shown  to  satisfy  the  final  Part  1 specifica- 
tion. A rule-of-thumb  (Ref  20:Sec  LI,  10)  suggests  that  it  the  sum  of 
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Fig.  9.  IDS  Image  Derotation  Intermediate  Bubble  Chart 


the  conceptual  data  streams  cut  by  the  afferent-transform  and 
efferent-transform  lines  is  at  a minimum,  then  a "better"  subsequent 
structure  chart  can  be  developed.  Note  that  this  sum  for  the  first- 
cut  bubble  chart  in  Fig.  4 is  ten.  The  sum  for  the  intermediate 
bubble  chart  in  Fig.  9 is  eight.  If  the  design  process  were  to  con- 
tinue at  this  point,  the  intermediate  bubble  chart  would  be  analyzed. 

If  appropriate,  the  afferent-transform  and  efferent-transform  lines 
may  be  moved.  For  example,  if  the  "Pod  status"  data  stream  in 
Fig.  9 were  to  be  moved  to  the  right  of  the  efferent  "cut,  " the  sum  of 
cuts  would  drop  to  six. 

T ransform/Transaction  Analysis  Technique.  Transform 
analysis  was  applied  to  the  "Performed  Target  Operations"  task 
(node  six)  from  Fig.  3.  Note  that  this  particular  task  was  shown  at 
an  abstract  level  in  order  to  reduce  complexity  of  the  state  diagram. 
This  task  actually  consisted  of  many  sub-tasks.  Figure  10  shows  the 
bubble  chart  for  this  abstract  task.  The  "level  of  observation"  for 
Fig.  10  was  purposefully  kept  high  for  this  discussion.  This  reduced 
superfluous  detail  at  this  point.  Note  that  the  transform  "Examine 
Selection  Data"  is  actually  a transaction  center  as  defined  by 
Constantine  (Ref  40:301-302).  This  indication  allows  the  use  of  a 
supporting  strategy  to  transform  analysis  called  transaction  analysis. 

Transaction  analysis  (Ref  40:301-329)  is  a technique  that  uses 
the  characteristics  of  a transaction  center  to  map  or  develop  a modu- 
lar software  structure  while  permitting  the  designer  to  also  use  the 
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effect.  A transaction  center  must  be  able  to  obtain  the  transaction, 
determine  its  type,  dispatch  on  that  type,  and  complete  the  processing 
of  each  transaction  (Ref  40:303).  The  major  steps  of  the  transaction 
analysis  strategy  are  (Ref  40:307-308): 

1.  Identify  the  source  of  the  transaction. 

Z.  Specify  the  appropriate  transaction-centered  organization. 

3.  Identify  the  transactions  and  their  defining  actions. 

4.  Note  potential  situations  where  modules  can  be  combined. 

5.  For  each  transaction,  or  cohesive  collection  of  transactions, 
specify  a "transaction"  module  to  completely  process  it. 

6.  For  each  action  in  a transaction,  specify  an  "action"  module 
subordinate  to  the  appropriate  transaction  module(s). 

7.  For  each  detailed  step  in  an  action  module,  specify  an 
appropriate  "detail"  module  subordinate  to  any  action 
module  that  needs  it. 

The  use  of  transaction  analysis  does  not  necessarily  produce  a struc- 
ture with  exactly  four  levels  of  processing.  Depending  on  the  "prob- 
lem" to  be  solved,  fully  factored  transactions  may  only  require  a 
single  transaction-level  module,  or  as  many  as  nine  or  ten  levels 
(Ref  40:308). 

Transform  analysis  was  also  applied  to  the  "Perform  Search 
Functions"  transform  of  Fig.  10.  This  increased  understanding  of 
the  function.  The  resulting  bubble  chart  is  shown  in  Fig.  11.  Note 
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that  another  transaction  center  existed.  Since  Fig.  10  was  developed 
at  a higher  "level  of  observation,  " application  of  the  transaction 
analysis  technique  would  have  resulted  in  a "pancake"  structure  chart. 
It  would  have  consisted  of  only  a transaction  level  (second  level). 

However,  application  of  the  transaction  analysis  steps  to  the 
bubble  charts  from  Figures  10  and  11  lead  to  the  development  of  the 
partial  structure  chart  shown  in  Fig.  12.  The  structure  chart  demon- 
strates the  result  of  using  the  transaction  analysis  technique.  If  the 
design  process  were  to  continue  at  this  point,  transform  analysis 
would  be  applied  to  the  "Track"  and  "Cue"  transforms  in  Fig.  10. 
Transaction  analysis  would  be  used  where  applicable. 

The  completed  "Perform  Search  Functions"  branch  of  the 
structure  chart  shown  in  Fig.  12  is  "classical"  (Ref  40:304).  How- 
ever, there  are  no  fixed  limits  on  the  number  of  levels  in  a structure 
chart  developed  as  a result  of  using  the  transaction  analysis  tech- 
nique. The  "detail  level"  shown  in  Fig.  12  resulted  from  further 
analysis  of  the  requirements  associated  with  the  bubble  charts  of 
Figures  10  and  11.  Note  that  the  modules  outlined  with  dashed 
rectangles  were  placed  in  their  appropriate  position  in  Fig.  12  to 
add  some  perspective,  and  show  their  relationship  with  respect  to 
the  search  function  previously  expanded.  The  "Calculate  Rate  Aiding" 
module  was  included  since  it  was  associated  with  the  cue  and  track 
functions.  Finally,  OFP  slant  range  data  was  required  for  each 
function  (i.  e.  Search,  Cue  and  Track).  Therefore,  the  slant  range 
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module  was  placed  at  the  "detail  level"  as  shown  in  Fig.  12.  It  was 
now  accessable  by  the  other  functions.  The  position  of  that  module 
was  significant.  Fan-in  was  increased,  and  perhaps  maximized.  In 
addition,  the  module  remained  highly  cohesive.  If  the  module  was 
coded,  the  increased  fan-in  would  reduce  coding  requirements  (Ref 
40:236,  308).  • 

Comments.  At  this,  point,  it  would  be  helpful  to  remember 
several  things.  Software  design,  regardless  of  the  technique  used, 
is  generally  subjective,  and  one  designer's  results  may  obviously 
vary  from  another  designer's  results.  When  using  the  transform  or 
transaction  analysis  tecluiiques  discussed  in  this  chapter,  a table  of 
input  and  output  parameters  for  each  level  (e.g.  first-cut)  of  struc- 
ture chart  should  be  developed.  Each  structure  chart  should  be 
fully  analyzed.  Several  alternate  structures  should  be  developed,  if 
appropriate,  for  comparison.  Finally,  a comparative  analysis  of 
alternate  structures  would  allow  the  designer  to  "find,  " with  confi- 
dence, the  "best"  structure  chart  for  a particular  level  (e.g.  the 
intermediate  structure  chart  level). 

Summary 

The  initial  and  revised  approaches  for  the  application  of 
several  design  methodologies  were  discussed.  For  the  initial 
approach,  the  unsuccessful  attempt  to  apply  transform  analysis  to 
the  PAVE  TACK  OP'P  was  discussed.  As  a result,  the  approach 
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was  modified. 


In  the  revised  approach,  several  design  techniques  were  suc- 
cessfully applied  to  the  PAVE  TACK  mainloop  and  discussed.  Each 
use  of  a technique  was  demonstrated  far  enough  into  the  design 
process  to  show  the  software  engineer/contract  monitor  "how  to  get 
started"  on  a design.  Use  of  an  OFP  Part  1 specification  as  a basis 
for  design  allowed  the  software  engineer /contract  monitor  a "place" 
to  start.  The  design  techniques  allow  further  understanding  of  the 
OFP  requirements.  They  also  allow  verification  of  requirements. 
Finally,  by  using  these  techniques,  the  software  engineer /contract 
monitor  is  in  a better  position  to  discuss  a particular  OFP  design, 
or  make  constructive  suggestions  on  an  in-process  OFP  design. 


V . Comparison  oi  Modification  and 
Life- Cycle  Effects 


Introduction 

This  chapter  discusses  two  hypothetical  software  modifications 
applied  to  a particular  task  and  module  of  the  PAYE  TACK  OFP 
mainloop.  New  designs,  from  the  previous  chapter,  effected  by 
these  modifications  are  briefly  examined  and  compared  to  the  current 
OFP  software.  Finally,  some  short  and  long  term  affects  associ- 
ated with  OFPs  designed  by  structured  design  tecliniques  are  dis- 
cussed. 


IDS  Image  De  rotation  Task  Comparison 

Current  Software.  The  IDS  Image  Derotation  task  is  currently 
implemented  as  a single  module  (Kef  o:6  1-o2).  In  Chapter  IV  this 
task  was  shown  as  an  IPO  scheme.  Also,  the  task  was  viewed  at  a 
certain  "level  of  observation"  which  permitted  easier  understanding. 
However,  since  the  current  software  equates  this  task  with  that  of  a 
module,  then  by  definition,  the  "level  of  observation"  is  lower,  and 
the  task  itself  will  be  examined  as  a module. 

The  current  "module"  for  image  derotation  has  certain  unde- 
sirable characteristics.  Coupling  and  cohesion  were  analyzed  by 
examining  the  OFP  product  specification  (Ref  c>:t>  1 -02,  Sec  X, 8°-90, 
Sec  XXX,  289-2°  11.  This  single  module  is  common  coupled  due  to 
its  various  reads  and  stores  to  a shared  global  data  structure.  It 
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has  procedural  cohesion  since  several  functions  are  grouped  within 
the  module  for  algorithmic  reasons.  This  was  immediately  ob\  ious 
when  the  coding  for  the  module  was  examined  and  compared  to  the 
module's  flowchart. 

Revised  Design.  In  Chapter  IV,  transform  analysis  was  used 
to  develop  a modular  structure  for  the  IDS  Image  Derotation  task. 

The  resulting  intermediate  structure  chart  in  Fig.  8 displays  the 
characteristic  of  functionality  within  the  structure.  The  modules  are 
minimally  coupled  and  maximally  cohesive  as  a result  of  transform 
analysis.  These  characteristics  reduce  complexity,  and  permit 
easier,  faster  modification  of  software  when  necessary. 

Sample  Modifica tion.  The  proposed  modification  is  hypotheti- 
cal, and  affects  the  current  software  and  revised  design  in  different 
ways.  The  modification  requires  that  the  derotation  angle's  com- 
puted rate  of  change  increment  also  be  used  in  the  computations  for 
derotation  of  the  hand  control  data.  Figure  13  shows  a simplified 
flowchart  of  the  current  image  derotation  "module."  Portions  of  the 
flowchart  effected  by  this  modification  are  denoted  with  an  asterisk. 
The  computations  for  the  derotation  angle  rate  of  change  increment 
are  located  at  (C)  on  Fig.  13.  To  accomplish  the  modification,  the 
hand  control  data  computations  at  (.A)  must  be  placed  immediately 
after  (C).  Since  the  flowchart  segment  at  (B)  uses  the  computed  hand 
control  data  from  \ A ) , segment  ^131  must  be  placed  immediately  after 
the  new  location  of  (A).  The  revised  flowchart  is  shown  in  Fig.  14. 
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Fig.  13.  Simplified  Flowchart  for  IDS  Image  Derotation 


^ef  0:Sec  X,  89-90) 
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After  actual  coding  of  the  module,  complete  retesting  of  all  effected 
functions  within  the  module  would  have  to  be  accomplished.  In  addi- 
tion, the  module's  input/output  interface  would  have  to  be  reverified. 
Finally,  the  time  required  to  accomplish  this  modification,  including 
recoding,  retesting,  implementation,  and  documentation  revision, 
would  obviously  add  some  fixed  cost  to  the  total  PAVE  TACK  software 
life-cycle  costs. 

For  the  revised  design  (Chapter  IV),  the  implementation  of  this 
modification  would  be  much  easier,  and  less  costly.  In  Fig.  8 the 
"Derive  Derotation  Hand  Control  Data"  module  (module  four)  and  the 
"Compute  Derotation  Angle  Rate  of  Change  Increment"  module 
(module  five)  are  located  at  the  second  level  in  the  structure  hart. 
Presently,  module  four  is  invoked  prior  to  module  five.  To  affect 
the  required  modification,  a simple  change  within  the  superordinate 
module  would  be  made  to  invoke  module  five  prior  to  module  four. 

This  change  would  permit  the  rate  of  change  increment  data  to  be 
passed  to  module  four  which  computes  the  derotated  hand  control 
data.  The  only  other  change  would  be  to  incorporate  the  rate  of 
change  increment  into  the  hand  control  data  computations.  Since  this 
module  would  remain  data  coupled  and  functionally  cohesive,  it  can 
be  easily  retested,  and  the  input/output  interface  quickly  redefined 
and  verified.  Finally,  since  the  implementation  of  this  modification 
is  easier  and  faster  in  the  revised  design  than  with  the  current 
"module,  " the  resulting  costs  are  much  less.  Obviously,  the  impact 


on  the  total  life-cycle  costs  is  less. 


Comment.  Although  this  hypothetical  modification  may  seem 
trivial,  the  effort  and  resulting  costs  of  more  complex  modifications 
will  follow  the  same  trend.  That  is,  modifications  will  generally  be 
easier,  faster,  and  cheaper  due  to  the  previously  discussed  implicit 
characteristics  normally  associated  with  a software  architecture 
developed  with  the  use  of  the  structured  design  methodology. 

Slant  Range  Modification  Comparison 

Sample  Modification.  This  modification  is  also  hypothetical, 
and  also  affects  the  current  software  and  revised  design  in  different 
ways.  The  modification  requires  a change  to  the  algorithm  used  to 
derive  slant  range.  At  this  point,  it  does  not  matter  what  the  actual 
change  is,  but  rather  that  there  must  be  a revision  to  the  algorithm 
for  slant  range. 

Current  Software.  In  the  current  PAVE  TACK  OFF,  slant 
range  is  derived  in  at  least  seven  different  modules.  It  is  not  diffi- 
cult to  understand  that  the  recoding  effort  would  take  time,  and  in 
fact,  would  be  somewhat  redundant.  All  effected  modules  would  have 
to  be  retested,  and  each  input/output  interface  reverified  against  the 
written  requirements.  The  total  cost  associated  with  recoding, 
retesting,  implementation  and  documentation  updating  would  be  added 
to  the  PAVE  TACK  total  life-cycle  costs. 
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Revised  Design.  As  shown  in  the  partial  structure  chart  in 
Fig.  12,  there  is  a single  module  for  slant  range  calculations.  It  is 
accessible  by  any  other  module  requiring  a slant  range  calculation. 

After  modifying  this  module,  retesting  and  input/output  interface 
reverification  would  be  accomplished.  The  module  would  still  remain 
highly  cohesive.  It  is  obvious  that  the  recoding,  retesting,  implemen- 
tation, and  documentation  updating  would  take  less  effort  and  time 
with  the  revised  design  than  in  the  current  software.  Finally,  the 
modification  costs  would  be  significantly  less. 

Short  Term  Effects  of  Structured  Des igned  OFPs 

Although  this  study  investigated  structured  design  techniques 
applied  to  only  part  of  the  FAVE  TACK  OFF  mainloop,  certain 
characteristics  associated  with  this  type  of  software  design  cause 
short  term  effects  worth  noting.  Some  of  the  effects  are: 

1.  Reduced  complexity  in  design  allows  easier  understanding 
of  that  design. 

2.  The  goal  of  low  coupling  between  modules  and  high  cohesion 
within  modules  permits  easier  and  less  complex  coding, 
testing,  and  integration. 

3.  Use  of  the  structured  design  methodology  has  an  overall 
effect  on  the  reduction  of  total  system  design  errors. 

4.  Since  the  software  architecture  of  a system  would  be  well 
defined,  management  can  refine  their  software  development 
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plan  as  well  as  revise  development  cost  estimates. 

5.  The  affects  mentioned  above  would  contribute  toward  a 
less  complicated  design  review. 

Long  Term  Efiec ts  of  Structured  Designed  QFPs 

In  a similar  manner,  the  same  type  of  characteristics  associ- 
ated with  structured  designed  software  also  cause  long  term  effects. 
Some  of  the  effects  are: 

1.  A total  system  is  more  easily  maintainable  and  manage- 
able. 

1.  The  total  system  is  more  flexible  to  changing  requirements. 

3.  Less  total  time  and  effort  are  consumed  in  making  revi- 
sions to  software. 

•4.  All  effects  (short  and  long  term)  would  contribute  toward 
the  reduction  of  total  life-cycle  system  costs. 

Summary 

It  was  obvious  from  the  two  hypothetical  modifications  that  the 
functionally  modular  structures  produced  (Chapter  IV)  by  using 
structured  design  techniques  responded  easily  and  effectively  to 
changing  requirements.  Modifications  were  discussed  for  the  IDS 
Image  Derotation  task  and  the  slant  range  algorithm.  Finally,  some 
short  and  long  term  affects  associated  with  OFF  software  designed 
by  structured  design  techniques  were  discussed.  Characteristics  and 
benefits  of  structured  designed  software  were  previously  discussed. 
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A generalized  OFP  familiarization /design  methodology  includes  some 
techniques  which  may  be  used  to  achieve  these  characteristics  and 
benefits,  and  is  described  in  the  next  chapter. 
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VI.  A Softwa re  Engineering  CEP 
Design  Methodology 

Introduction 

This  chapter  describes  a suggested  software  engineering  OFP 
design  methodology  developed  for  Air  Force  avionics  software 
engineers /contract  monitors.  The  need  for  such  a methodology  is 
briefly  discussed  as  well  as  the  objective  and  goals  established  to 
develop  it.  The  methodology  consists  of  three  phases:  (11  understand- 
ing the  flight  program  requirements;  (2)  use  of  a technique  for  under- 
standing flight  program  tasks  and  task  sequencing;  and  (3)  use  of 
structured  design  techniques  for  flight  program  tasks.  Each  phase  is 
discussed. 

General 

Software  engineers  monitoring  the  development  of  avionics 
flight  software  (e.g.  operational  flight  programs)  often  rely  com- 
pletely on  the  software  developers' choice  of  design.  They  acc  ept 
the  software  end-item  without  much  input  to  the  producer  about 
design  during  preliminary  design  of  the  software  architecture.  A 
good  software  design  requires  discussion  of  design  alternatives 
between  the  developer  and  user.  This  interaction  should  result  in  a 
mutually  agreeable  design  which  also  satisfies  the  particular  flight 
software  w ritten  requirements  definition  (Part  I specification).  In 
order  for  the  software  engineer  to  effectively  participate  in  and 
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monitor  the  development  of  an  OFP,  it  would  be  beneficial  to  have  a 
software  engineering  methodology  which  would  permit  a more  effi- 
cient and  effective  evaluation  of  OFP  design  alternatives.  The 
methodology  could  also  be  vised  to  verify  the  software  developers 
interpretation  of  the  written  requirements  definition. 

Use  of  this  methodology  by  a software  engineer /contract  moni- 
tor permits  establishment  of  various  stages  of  familiarization.  This 
important  effect  allows  two  primary  uses  of  the  methodology.  First, 
the  user  of  this  methodology  can  gain  a greater  understanding  of  the 
OFP  requirements  definition  (draft  Part  I specification).  Second,  the 
user  may  develop  a separate  OFP  design  for  familiarization.  The 
latter  not  only  permits  greater  understanding  of  requirements,  but 
more  importantly , allows  more  detailed  and  thorough  discussions 
between  the  software  engineer /contract  monitor  and  the  software 
producer  abovit  OFP  design  alternatives. 

Requirements  fo r Methodology  Development 

To  help  develop  a useful  and  meaningful  methodology,  an  objec- 
tive and  accompanying  goals  were  established.  The  objective  was  to 
develop  an  OFP  design  methodology  or  approach  which  would  assist 
or  aid  software  engineers /contract  monitors  (the  methodology  user 
in  this  case)  in  the  initial  understanding  and/or  design  of  OFP  soft- 
ware from  a draft  Part  1 specification.  It  was  desirable  to  include 
the  finite-state  technique  and  the  techniques  of  structured  design  as 
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demonstrated  in  Chapter  IV. 


A reachable  set  of  goals  were  developed.  The  goals  were: 

1.  The  approach  should  aid  the  user  from  a practical  point  of 
view  if  it  is  to  be  useful. 

2.  It  should  be  simple  enough  to  allow  a free -flow  development 
of  ideas  for  the  design,  yet  comprehensive  enough  to  be 
useful. 

3.  It  should  be  understandable  in  order  to  facilitate  ease  of  use 
and  maximize  information  transfer  to  the  user. 

4.  It  should  be  flexible  in  order  to  permit  use  on  different  OFP 
requirement  definitions. 

5.  It  should  allow  hardware  independence  during  design. 

Design  Methodology 

The  design  methodology  may  be  applied  in  three  phases.  Phase 
one  consists  of  understanding  the  problem  to  be  solved.  Phase  two 
suggests  the  steps  to  be  taken  for  application  of  the  finite-state  tech- 
nique to  OFP  tasks.  Finally,  phase  three  will  complete  the  prelimi- 
nary design  by  application  of  the  structured  design  techniques.  The 
software  engineer /contract  monitor  may  stop  at  the  end  of  any  phase. 

Use  of  each  successive  phase  lowers  the  "level  of  observation" 
applied  to  the  "problem"  and  increases  understanding  of  the  overall 
OFP  design. 

f 
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Phase  1.  In  phase  one,  there  are  certain,  and  probably  obvious, 
steps  that  can  be  taken  by  the  user  to  understand  the  ’ problem"  to  be 
solved.  In  this  case  the  problem  is  to  understand  the  requirements 
for  the  development  of  a viable  OFP  design.  A top-down  approach  is 
suggested  for  understanding  those  requirements. 

The  understanding  "process"  is  started  by  achieving  a thorough 
understanding  of  the  software  system  specification.  Mission  and 
technical  requirements  of  the  OFP  are  explained  in  the  specification 
as  well  as  functional  areas,  programming  language  requirements, 
design  standards,  and  so  forth.  The  system  specification  establishes 
the  initial  functional  baseline  for  the  system  (Ref  2:15).  To  further 
decompose  the  problem  and  increase  understanding,  the  next  sug- 
gested step  in  phase  one  is  to  obtain  the  written  requirements  defini- 
tion. 

It  will  be  necessary  to  gain  a detailed  understanding  of  the 
written  requirements  definition.  The  draft  Part  I software  specifi- 

I I 

cation  contains  the  particular  written  requirements  for  the  design, 
development,  functional  performance,  test  and  qualification  of  the 
OFP  (Ref  2:15).  The  draft  Part  I specification  will  be  used  as  the 
"basis  for  design"  in  the  remaining  phases  of  this  design  methodology. 

Finally,  familiarization  with  any  written  assumptions  and  limi- 
tations associated  with  the  OFP  is  suggested.  They  may  be  required 
or  useful  during  the  design  process.  The  assumptions  and  limita- 
tions car  usually  be  obtained  from  either  the  system  or  draft  Part  I t 


68 


specification,  or  both.  Implementation  and  hardware  information  is 


"nice  to  know,"  but  inclusion  of  such  information  during  the  prelimi- 
nary design  should  be  avoided.  This  type  of  information  will  be  useful 
later  during  the  detailed  design  \e.g.  algorithm  implementation,  tim- 
ing, etc.  1.  The  preliminary  design  process  should  remain  free  of 
biases  or  limitations  since  the  resulting  OFF  design  may  be  unduly 
affected.  If  deeper  understanding  of  the  OFF- is  desired,  or  the  soft- 
ware  engineer /contract  monitor  must  develop  a high-level  ("level  of 
observation"!  OFF  design,  the  initial  steps  are  suggested  in  phase 
two. 

Phase  H.  In  phase  two  a basic  sequence  of  steps  are  suggested 
for  the  application,  where  applicable,  of  the  finite-state  technique  as 
discussed  in  Chapter  IV.  In  Chapter  IV  a particular  OFP  mainloop 
contained  tasks  represented  as  an  IPO  scheme  for  a particular  "level 
of  observation.  " Typically,  the  IPO  relationship  will  hold  for  OFP 
mainloop  tasks  as  well  as  some  tasks  (e.  g.  built-in-testing)  found  in 
OFP  executives.  Therefore,  the  software  engineer /contract  monitor 
can  use  the  suggested  steps  in  this  phase  for  a "first  interpretation" 
of  the  requirements  definition  and  preliminary  design. 

The  finite- state  technique  is  applied  to  the  OFP  major  tasks  in 
the  same  manner  as  discussed  in  Chapter  IV.  In  addition  the  soft- 
ware engineer /contract  monitor  should  write  a brief  description  of 
each  major  task  in  the  OFP.  Each  task  description  should  represent 

an  individual  rewritten  interpretation  of  the  requirements  from  the  I 
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draft  Part  1 spec ification.  It  is  important  at  this  point  in  time  that 
the  designer's  interpretation  of  task  requirements  and  the  task  state 
diagram  be  committed  to  paper.  In  addition  to  the  notation  described 
in  Chapter  IV  for  use  with  this  technique,  part  of  Appendix  D contains 
some  additional  task  description  notation  which  may  be  helpful. 
Abstraction  can  be  used  where  appropriate  to  simplify  the  state  dia- 
gram. Abstraction  was  demonstrated  in  Chapter  IV  ii.  e.  "Perform 
Target  Operations"). 

The  written  interpretations  of  tasks  and  the  validity  of  the  state 
diagram  should  be  verified  against  the  requirements  definition  ti.e. 
draft  Part  I specification)  for  any  misinterpretations.  Where  appro- 
priate, the  system  specification  may  be  used.  However,  the  draft 
Part  1 specification  should  contain  all  information  necessary  for 
design.  If  it, doesn't,  it  may  be  inconcise,  incomplete  or  ambiguous. 
Appropriate  corrective  action(s)  should  be  taken  to  correct  the  draft 
Part  1 specification  if  this  problem  exists. 

A viable  task  state  diagram  and  accompanying  task  descrip- 
tions may  need  revision  \e.g.  an  error  exists  in  the  diagram). 
Correct  or  modify  the  task  state  diagram  as  necessary.  Clarify 
written  task  descriptions  where  appropriate.  When  these  steps  are 
completed,  the  user  is  ready  to  proceed  to  the  final  steps  in  this 
phase. 

At  this  point,  if  time  permits,  it  is  worthwhile  to  initiate  a 
"reader  cycle."  The  written  OFP  design  interpretation  can  be  given 
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to  another  knowledgeable  person  for  a critique.  The  reader  should 
(also)  use  the  draft  OFP  Part  I specification  to  verify  the  software 
engineer/contract  monitor's  design  interpretation.  Comments  should 
be  written  by  the  reader,  and  no  form  of  communication  should  take 
place  between  the  two  people  concerned  before  or  during  the  critique 
process. 

At  the  completion  of  the  reader's  critique,  existing  discrep- 
ancies should  be  discussed  with  the  reader.  The  software  engineer/ 
contract  monitor  should  correct  or  modify  any  valid  discrepancies 
noted.  When  these  steps  are  complete,  two  products  of  this  phase 
should  exist:  a final  task  state  diagram  and  clear,  concise,  unam- 
biguous written  task  descriptions. 

Phase  two  is  now  complete.  The  designer  may  stop  at  this 
point  or  proceed  to  phase  three.  This  decision  can  depend  on  many 
factors.  However,  the  two  most  important  factors  are  the  depth  of 
understanding  needed  and  the  level  of  familiarization  desired.  Com- 
pletion of  phase  three  in  this  methodology  should  result  in  a total 
understanding  of  the  OFP  preliminary  design  requirements.  The 
software  engineer /contract  monitor  should  in  fact  end  up  with  a 
viable  OFP  preliminary  design.  However,  a prime  objective  at  the 
completion  of  phase  three  would  be  a discussion  of  OFP  design 
alternatives  or  suggestions  about  an  "in-process"  design  with  the 
software  producer. 
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P ha s o 111.  In  this  phase,  the  structured  design  methodology  is 
applied  to  individual  OFF  tasks  (state  diagram  nodes).  The  struc- 
tured design  methodology  can  be  used  as  discussed  in  Chapter  IV. 

The  transform  analysis  leclmique  is  applied  to  each  "defined"  task. 
Either  the  Constantine  or  Hughes  version  of  this  technique  may  be 
used  by  the  software  engineer/contract  monitor.  If  transaction 
centers  are  revealed,  the  transaction  analysis  technique  is  used. 

This  technique  was  also  discussed  in  Chapter  IV.  The  structured 
design  process  continues  until  the  final  task  structure  charts  are 
completed,  including  their  supporting  information. 

At  the  completion  of  phase  three  the  software  engineer/contract 
monitor  should  have  a detailed  understanding  of  the  OFF  require- 
ments plus  a final  documentation  package  to  support  that  understand- 
ing. The  information  contained  in  the  final  documentation  package  i6 
easily  transferable  to  another  person.  It  should  include: 

I.  If  applicable,  a task  state  diagram  (from  phase  two;  and 
concise  written  descriptions  lor  each  task  shown  on  the 
diagram. 

J.  Final  bubble  charts  which  directly  reflect  the  requirements 
detinition  for  each  defined  task. 

>.  A tin.il,  fully  annotated  structure  chart  for  each  task  which 
••  prr-ents  the  hierarchical  software  structure  developed 
it  >-o«.iated  final  bubble  chart. 


Fig.  14  (continued) 


4.  A written  functional  description  of  each  module  of  each 
final  task  structure  chart. 

5.  A final  module  input  and  output  parameter  table  for  each 
final  task  structure  chart. 

o.  A final,  full  analysis  of  module  coupling,  cohesion,  scope- 
of-effect  and  scope-of-control  for  each  final  task  structure 
chart. 

Obviously,  the  software  engineer /contract  monitor  can  use  the  final 
task  state  diagram  and  final  task  structure  charts  together  for  an 
overall  system  representation  and  viewpoint.  The  final  documenta- 
tion package  can  now  be  used  for  technical  and  management  in-house 
discussions  and  briefings  as  well  as  backup  information  for  technical 
discussions  of  design  alternatives  with  a software  producer. 

Limitation 

Use  of  the  finite-state  tecluiique  in  this  methodology  was 
limited  to  non-concurrent  processes.  The  technique  was  discussed 
in  Chapter  IV  and  successfully  applied  to  the  PAVE  TACK  OFP  main- 
loop.  The  mainloop  processing  was  sequential.  Concurrent 
processes  are  beyond  the  scope  of  this  study. 


effectively.  The  general  need  for  such  a methodology  was  briefly 
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discussed  as  well  as  the  objective  and  goals  established  to  develop 
this  methodology.  The  design  methodology  or  guideline  consisted  of 
three  phases  and  each  phase  was  described.  Use  of  this  methodology 
also  permits  the  software  engineer /contract  monitor  to  verify  the 
OFF  software  developers  interpretation  of  the  written  requirements 
definition. 
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Introduction 

This  chapter  highlights  the  results  and  conclusions  of  this  study. 

Objectives  for  this  investigation  were  met.  Recommendations  are 
made  for  future  avionics  efforts. 

Results 

A modified  finite-state  technique  was  successfully  applied  to  the 
PAVE  TACK  OFP  mainloop.  A state  diagram  was  developed.  Each 
node  of  the  state  diagram  represented  an  OFP  mainloop  task.  The 
diagram  displayed  proper  sequencing  of  the  mainloop  tasks.  This 
technique  was  limited  to  non-concurrent  processes.  The  task  state 
diagram  directly  reflected  the  mainloop  control  structure. 

The  transform  analysis  and  transaction  analysis  techniques 
were  successfully  applied  to  separate  OFP  mainloop  tasks.  Initially 
transform  analysis  did  not  work  when  applied  to  the  entire  mainloop 
since  each  separate  task  functioned  as  an  input-process -output 
scheme.  Data  were  not  passed  directly  between  tasks.  Therefore, 
attempts  to  create  a mainloop  bubble  chart  produced  invalid  results. 

However  after  revising  the  approach,  separate  task  bubble  charts  and 
structure  charts  were  successfully  developed  and  analyzed.  Coupling, 
cohesion,  scope-of- effect  and  scope-of-control  were  examined. 

During  an  application  of  transform  analysis,  transaction  analysis  was 
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applied  when  transaction  centers  were  discovered.  A structure  chart 
was  developed  and  analyzed. 

Two  hypothetical  modifications  were  made  to  certain  parts  of 
the  redesigned  OFP.  The  modifications  were  easily  made  and  con- 
sumed little  time.  Modification  costs  were  reduced  with  structured 
design  software  when  compared  to  the  current  PAVE  TACK  OFP  soft- 
ware. 

A generalized  OFP  familiarization  and  design  methodology  was 
proposed.  It  provides  guidance  for  using  the  finite- state  and  struc- 
tured design  techniques.  A software  engineer /contract  monitor 
participating  in  or  monitoring  the  design  and  development  of  an  OFP 
can  use  a draft  Part  1 specification  and  these  techniques  to  gain  an 
understanding  of  design  requirements.  The  software  producers 
interpretation  of  an  OFP's  requirements  can  also  be  verified  at  the 
preliminary  design  review  (PDR). 

Conclusions 

The  bubble  chart  used  in  the  transform  analysis  technique  is  a 
graphical  representation  of  the  requirements  definition.  It  helps  the 
user  of  the  technique  to  understand  the  requirements.  In  addition,  it 
can  be  used  to  verify  the  requirements  of  the  (draft)  Part  I software 
specification.  Inconcise  w ritten  descriptions  of  OFP  tasks  and  incon- 
sistent terminology  used  to  describe  different  tasks  are  readily 
discovered.  Areas  of  superficial  or  extremely  detailed  OFP 
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information  are  easily  detected  with  the  use  of  a bubble  chart. 

The  OFF  requirements  definition  in  a Part  1 specification  must 
be  complete,  concise  and  unambiguous.  Requirements  written  in 


"natural"  English  satisfy  familiarization  needs,  but  not  OFP  design 
needs.  The  OFP  requirements  should  not  be  so  loosely  written  that 
the  software  producer's  "experience"  will  be  expected  to  provide  the 
missing  information.  M1L-STD-483  and  MIL-STD-490  (Ref  3:Sec  II, 
28-32)  are  reasonable  guidelines  for  development  of  a Part  I specifi- 
cation, but  specific  methodologies  should  be  specified  to  the  software 
producer  for  requirements  analysis  and  design.  This  will  help  ensure 
complete,  concise  and  unambiguous  software  specifications,  and  a 
"better"  OFP  design. 

Due  to  the  scope  of  this  study,  a partial  conclusion  was  drawn 
about  the  techniques  used  in  this  study  applied  to  an  OFP  executive. 

No  attempt  was  made  to  show  conclusively  that  the  finite-state  tech- 
nique could  be  applied  to  develop  a total  OFP  executive.  Also,  the 
structured  design  techniques  were  not  applied  to  OFP  executive  tasks. 
Concurrent  processes  were  not  considered  in  this  study.  However, 
based  on  the  successful  results  of  applying  these  techniques  to  an 
OFP  mainloop  not  involving  concurrent  processes,  these  techniques 
can  be  applied  in  the  same  manner  to  an  OFP  executive  of  the  same 
class  (non-concurrent)  of  processes. 

Use  of  the  OFP  familiarization  and  design  methodology  sug- 
gested in  this  report  should  permit  early  interaction  with  the  software 
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producer  concerning  OFP  design  alternatives.  In  choosing  the  proper 
alternative,  consideration  should  also  be  given  to  the  software  mainte- 
nance aspect  due  to  the  changing  requirements  normally  associated 
with  OFPs.  Use  of  this  methodology  by  the  software  engineer/con- 
tract monitor  will  obviously  depend  on  personal  time  available  and 
the  project  schedule.  The  availability  of  a draft  Part  I specification 
prior  to  PDR  will  also  affect  "how  much"  of  the  methodology  can  be 
used  on  a particular  OFP. 

Recommendations 

Requirement  analysis  and  design  methodologies  or  techniques 
should  be  specified  in  the  statement  of  work  written  by  the  software 
engineer /contract  monitor.  The  goal  is  to  obtain  a complete,  con- 
cise and  unambiguous  requirements  definition  and  the  "best"  OFP 
design.  Requirements  analysis  /definition  methods  such  as  Struc- 
tured Analysis  (Ref  30;  31;  32;  33),  Problem  Statement  Language/ 
Problem  Statement  Analyzer  (PSL/PSA)  (Ref  35)  or  SREM  ^Ref  9) 
are  suggested.  Structured  Design  (Ref  20;  21;  40)  or  Composite 
Design  (Ref  26)  are  suggested  for  preliminary  OFP  design  in  addition 
to  the  Finite-state  technique  discussed  in  this  report.  If  Structured 
Analysis  is  used  for  requirements  analysis,  a method  exists  that 
permits  an  easy  transition  to  the  structured  design  teclmiques  (Ref 
23:71-43).  Finally,  any  deviations  in  the  basic  OFP  design  that 
changes  the  task  design  (structure  charts)  to  facilitate  OFP 
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implementation  should  be  described  by  the  software  producer  in  the 
Part  II  specification. 

The  requirements  analysis  and  design  methods  previously  sug- 
gested obviously  will  not  solve  all  the  requirements  and  design 
engineering  problems.  However,  use  of  these  methods  will  signifi- 
cantly reduce  the  problems.  Better  OFP  designs  will  be  the  result. 

The  required  effort  and  time  will  be  less  for  OFP  modifications  to 
meet  changing  requirements,  and  thus,  total  software  life-cycle  costs 
will  be  reduced. 
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Appendix  A 


F rief  Discussion  of  Operational  Flight  Prop  rani  Concepts 

Avionic  software  can  be  categorized  as  either  mission  or  sup- 
port software.  Mission  software  executes  within  a flight  computer 
^on-board  computer)  and  performs  mission-related  functions.  A 
frequently  used  analogous  term  is  "embedded"  software.  Support 
software  aids  in  the  design  and  production  of  avionic  systems  (Ref 
37:998). 

Mission  software  can  be  further  divided  into  two  sub-categories 
The  first  is  real-time  functions,  which  are  performed  with  an  OFP, 
and  the  second  is  system  testing  which  is  performed  with  an  opera- 
tional test  program  (Ref  37:999). 

The  OFP  contains  functions  which  are  executed  in  a flight  com- 
puter in  real-time  (or  near  real-time),  and  perform  the  primary 
aircraft  mission  functions  such  as  executive  control,  navigation, 
guidance,  targeting  and  display  processing  (Ref  37:u99).  A combina- 
tion of  these  functions  is  not  normally  found  in  ADP  software.  Also, 
the  OFP  is  often  used  to  close  avionic  control  loops.  These  may 
range  from  relatively  slow  control,  such  as  range  update  of  naviga- 
tion parameters,  to  rapid  control  in  a critical  airc raft/missile 
control  loop  function  which  must  be  completed  in  a few  milliseconds. 
The  requirement  may  exist  for  displaying  all  pertinent  information 
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for  aircrew  evaluation  and  reaction  in  real-time  where  aircrew  safety 
is  directly  involved,  and  as  a result,  the  software  becomes  consider- 
ably more  integrated  and  complex.  The  OFP  can  also  be  used  to  per- 
form continuous  checking  of  specified  hardware  parameters.  Finally, 
the  requirement  may  exist  for  absolute  software  program  correctness 
so  that,  conceivably,  the  OFP  might  be  used  to  control  the  release  of 
a nuclear  weapon.  It  is  easy  to  see  that  functional  requirements  are 
quite  different  from  normal  ADP  (Ref  10:476). 

Inputs  to  an  OFP  generally  originate  from  sensors  via  analog-to- 
digital  converters,  and  control  actions  are  automatically  taken  without 
a stored  record  of  the  input  which  caused  them  (some  applications 
require  a stored  "snap-shot"  of  certain  system  or  program  parameters 
on  a flight  recorder).  This  type  of  closed-loop  operation  can  depend 
upon  a variety  of  hardware  devices,  each  one  having  many  failure 
modes  not  necessarily  predictable.  Therefore,  recovery  and  real- 
time  control  requirements  exist,  and  the  software  must  continue  to 
operate  in  a reliable  manner  regardless  of  any  hardware  problems 
that  may  occur  (Ref  10:476). 
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Appendix  B 


Bubble  Chart  Symbol  Descriptions 


The  following  symbols  are  used  in  this  report  and  are 
described  as  follows  (Ref  40:54-62,  565-566): 


Symbol 


Name 


* 


Example: 


Description 

The  circle  represents  a transform  of  data  from  one 
form  to  another.  "Name"  identifies  the  transform 
process  and  is  a verb  or  verb  phrase. 

The  labeled  arrow  represents  a data  stream  either 
entering  an  initial  transform,  leaving  a final  trans- 
form, or  connecting  one  transform  to  another. 
"Name"  identifies  the  data  stream  and  is  a noun  or 
a noun  phrase. 

The  asterisk  represents  the  conjunction  operator 
which  is  used  to  denote  the  "AND"  function  of  data 
streams. 

The  ring-sum  symbol  represents  the  disjunction 
operator  which  is  used  to  denote  the  "EXCLUSIVE- 
OR"  function  of  data  streams. 
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Appendix  C 


Structure  Cha rt  Symbol  Desc rxptionB 


The  following  symbols  are  used  in  this  report  and  are  described 
as  follows  (Ref  40:547-552,  589-699): 


Symbol 


Name 


O 


O 


Desc  ription 

A simple  rectangle  represents  a module.  "Name" 
is  the  module  name  and  is  a verb.  A descriptive 
verb  phrase  may  be  used  in  place  of  a single  name. 

An  arrow  with  a dot  on  its  tail  denotes  control 
information. 

An  arrow  with  a small  circle  on  its  tail  denotes 
data. 

A diamond  denotes  a conditional  decision  embedded 
in  a module. 


X A plain  labeled  arrow  represents  the  super-ordinate- 

subordinate  reference  to  a module.  "X"  may  be  used 
to  represent  the  Arabic  number  identifier  of  the 
subordinate  module. 


! 

I 


I 


i 


I 


Example: 
(Structure  Chart) 


(Table) 


Pa  rametere 


Module 

Input 

Output 

1 

— 

XVALVE 

6 

— 

XVALUE  (RAW) 

7 

XVALUE  (RAW) 

OKFLAG 

8 

XVALUE (RAW) 

XVALUE  (SCALED) 
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Appendix  D 


Symbols  and  Notation  tor  l1  se  with 
Finite  -State  Technique 

The  following  symbols  and  notation  may  be  used  to  extend  the 
finite-state  technique  (discussed  in  Chapters  IV  and  VI): 


Symbol  or 
Notation 


NAME/Z 


TiU.P.O.t) 


IV sc  ription 

The  circle  represents  a node  or  task  on  the  task 
state  diagram.  "X”  is  an  Arabic  number  which 
denotes  the  node  identifier.  "l’ROCKSS"  is  a verb 
or  verb  phrase  that  identifies  the  task  process. 
This  task  is  preemptable. 

Same  description  as  above  except  that  the  double 
circle  represents  a non-preemptable  task. 


This  directed  line  or  arc  represents  a transfer  of 
control  from  one  task  to  another.  "NAME"  identi- 
fies the  condition  of  transfer. 

This  dashed  line  or  arc  also  represents  a transfer 
of  control  from  one  task  to  another,  but  in  addition, 
control  information  may  be  passed  to  the  next  task. 
"7."  represents  t he  control  information  identifier. 

A 4-tuple  may  be  used  to  identify  certain  informa- 
tion to  be  associated  with  or  contained  in  a written 
description  of  task  number  i.  "1"  and  "O"  are 
identifiers,  each  of  which  represents  a set  of 
numbers.  Each  set  contains  Arabic  numbers  that 
identify  the  major  input  and  output  data  associated 
with  task  i after  task  i is  initiated  and  before  it 
terminates.  "1>U  is  an  identifier  which  represents 
the  written  description  of  the  task  i process,  "t" 
is  the  time  allowed  (in  some  convenient  time  unit) 
for  completion  of  task  i processing.  The  4-tuple 
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notation  for  each  task  can  be  annotated  onto  the 
task  state  diagram.  Some  convenient  method  may 
be  used  to  associate  the  4-tuple  notation  with  the 
task  or  node  representing  the  task  te.g.  a 
"squiggle  arrow," — Note  that  a f>-tuple,  Ti 
(l.P.O,  t-min,  t-max),  could  be  used  for  task  i 
if  a minimum  and  maximum  time  for  task  comple- 
tion are  applicable. 
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